Level 4 · Master Production¶
Goal: run a FastAPI service the way production demands — measured, observable, hardened, able to evolve without breaking clients, and correct when many processes serve it at once.
Three ideas carry this level:
- Measure before and after. Lesson 1's most useful result — that removing a response model made an endpoint five times slower — is the opposite of what intuition said. Profile, load-test, and trust the numbers from your own hardware.
- Production is many processes behind a proxy. Workers, forwarded headers,
root_path, graceful shutdown, per-process state: most "works on my machine" bugs live in the gap betweenfastapi devand this. - Correctness lives in the database. Atomic
UPDATE ... WHERE, unique constraints for idempotency, leases for job claiming — the capstone sells exactly 50 seats out of 200 concurrent requests across four processes because of a single SQL statement, not because of locks in Python.
Modules¶
- Performance: Finding Blocking Code and Measuring Throughput —
ab, pyinstrument in the right event loop, asyncio debug mode, workers for CPU work - Running in Production: Workers, Gunicorn & Containers — the supervisor, crash recovery, graceful shutdown, a Dockerfile
- Behind a Reverse Proxy — forwarded headers, who to trust,
X-Forwarded-Forspoofing,root_path - Observability: Structured Logs, Request IDs & Metrics — JSON logs, the error-path request-ID bug, Prometheus, FastAPI's built-in OpenTelemetry
- Security Hardening Against the OWASP API Top 10 — mass assignment, body limits, SSRF, path traversal, debug leaks
- Versioning and Evolving an API — additive vs breaking, v1/v2 routers, deprecation headers, an OpenAPI diff check
- Long-Running Work: Job Queues and Polling — a durable job table, atomic claims, leases, retries, idempotency
- Advanced Patterns — RFC 9457 problem details, custom route classes, mounted sub-apps
- Upgrading: Pydantic v1 to v2 and FastAPI Releases — silent behaviour changes, codemod pitfalls, warnings as errors
- Capstone — A Production-Ready Event Booking API — everything above, with a multi-process overbooking test
What you need before starting¶
- Levels 1–3 of this course. The capstone reuses async SQLAlchemy, Alembic, settings, JWT verification, scopes and the async test fixtures.
- Comfort with a terminal: processes, signals, environment variables. The Shell Mastery Path and Server Ops Mastery Path cover the background.
- For containers and orchestration, see the Docker Mastery Path and Kubernetes Mastery Path; for the HTTP design side of versioning, the REST API Mastery Path.
How the examples were checked¶
Everything ran on one 8-core laptop with Python 3.14.7, FastAPI 0.143.0,
Uvicorn 0.54.0, Gunicorn 26.2.0, SQLAlchemy 2.1.4, Alembic 1.20.0,
prometheus-client 0.26.0, OpenTelemetry SDK 1.45.1, pyinstrument 5.1.3 and
bump-pydantic 0.8.0, with SQLite 3.53.4. Load tests used ApacheBench (ab) on the
same machine as the server; worker, crash and shutdown behaviour was observed on real
Uvicorn processes with ps, kill and curl.
What wasn't run
Docker, nginx, PostgreSQL, Redis and a real tracing backend weren't available. The
Dockerfile (lesson 2) and nginx configuration (lesson 3) are marked as unbuilt and
untested; proxy behaviour was simulated by sending forwarded headers directly to
Uvicorn; PostgreSQL-specific statements (FOR UPDATE SKIP LOCKED, row-lock
behaviour) are described from documented behaviour. Throughput numbers are one
machine's and are for comparing alternatives, not for capacity planning.