Core Backend Platform
Major parts of the async FastAPI backend behind bettrlabs.com: a layered API, one consistent response contract, PostgreSQL with Alembic migrations, an LLM gateway that meters every call, and AI runs that survive restarts.
- ownership
- Engineered major components
- when
- 2025 - 2026
- org
- Bettrlabs
The film, as text: Core Backend Platform. Major parts of the async FastAPI backend behind bettrlabs.com: a layered API, one consistent response contract, PostgreSQL with Alembic migrations, an LLM gateway that meters every call, and AI runs that survive restarts. Layered request path: Each request passes through API, validation, service and data layers, one job each. Service agent: An LLM-backed service agent turns a plain requirement into a structured service request. PostgreSQL + Alembic: Async SQLAlchemy on PostgreSQL, with Alembic as the only schema authority on one chain. Clean API responses: A Pydantic schema trims each row to what the client needs, inside one JSON envelope. One LLM gateway: Every model call goes through one client: fallback, retry, per-call usage, separate logs. Durable background runs: A run holds a heartbeat lease; if its worker dies, another takes over the same run id. Tested end to end: Unit, API, migration and end-to-end suites run with pytest. Engineered major components, Bettrlabs, 2025 - 2026.
Problem.
An AI product backend is a web backend plus a model layer that costs money on every call, fails in provider-specific ways and runs for minutes at a time. It has to keep its API contract stable for the frontend and finish long model runs even when a deploy restarts the process.
How it works
- Layered backend: clear separation between the API, service and data layers, with only the abstractions the code needs. Typed Pydantic schemas and one JSON response envelope with error codes return only the fields the client needs, and OpenAPI documentation is generated from the code.
- PostgreSQL and Alembic: async SQLAlchemy over PostgreSQL, with SQLite for local development, and schema changes made only through Alembic migrations.
- One LLM gateway: every model call goes through a single LiteLLM client with model fallbacks and retries. Each call logs its token usage and cost, alongside structured logging and error tracing for production debugging.
- Durable background jobs: long model-backed jobs hold a heartbeat lease, so another worker can recover them after a crash without losing or duplicating a result.
- Service agent: an agent turns a user’s requirements into a service request.
- Testing and delivery: pytest suites for unit, API, migration and end-to-end flows, pull-request review, and backend deployment (FileZilla, PuTTY, SSL).
Stack
- Backend
- Python 3.12
- FastAPI
- Pydantic
- Async SQLAlchemy
- REST APIs
- Heartbeat-lease background jobs
- Data
- PostgreSQL
- SQLite
- Alembic
- LLM infrastructure
- LiteLLM
- Model fallbacks
- Token and cost tracking
- Quality
- pytest
- Structured logging
- Error tracing
- Tooling
- uv
- OpenAPI