Architecture

FastAPI does not reimplement HTTP handling or data validation — it composes two libraries that already solve those problems well, and adds a thin, opinionated layer connecting them: route introspection, a dependency-injection graph, and automatic schema generation.

Request lifecycle

1. An ASGI server (Uvicorn/Hypercorn) accepts the connection and calls into Starlette's router.
2. Starlette matches the path and method to a registered APIRoute.
3. FastAPI's request_response() adapter wraps the plain Python function into an ASGI-compatible callable.
4. solve_dependencies() walks the route's dependency graph — built once, at startup, via inspect and typing.get_type_hints() — and resolves every Depends(...) in topological order, reusing sub-dependencies that appear more than once in the same request.
5. Path, query, header, cookie, and body parameters are validated and coerced by Pydantic; a failure raises RequestValidationError and short-circuits to a 422 response before the endpoint ever runs.
6. The endpoint function executes.
7. The return value is validated against the declared response_model (if any) and serialized back to JSON.
8. Any generator-based dependencies (yield) run their teardown code inside an AsyncExitStack, guaranteed to execute even if the endpoint raised.

Design principle: introspection happens once

The expensive part — inspecting a function's signature to determine what's a path parameter, query parameter, header, or dependency — happens exactly once, when the route is registered at startup, not on every request. The result is cached as a Dependant object attached to the route. This is why FastAPI's per-request overhead stays close to Starlette's despite the amount of declarative behavior layered on top.