How do you manage service lifecycle with FastAPI Depends versus formal DI?

WHAT THIS TESTS: This question probes your ability to scale dependency injection beyond tutorial-level examples. FastAPI's Depends is powerful for request-scoped resources, but large applications need clear lifecycle boundaries between long-lived singletons, per-request state, and transient objects. The interviewer wants to see that you understand when framework-native DI becomes a liability and how to compose it with explicit architectural patterns.

A GOOD ANSWER COVERS: First, the candidate should explain that Depends with yield is ideal for request-scoped infrastructure such as database sessions, HTTP clients, or authentication context, because FastAPI manages the cleanup after the request ends. Second, they should argue that a formal DI container or manual registry becomes valuable when service graphs grow deep, when business logic must be composed outside of HTTP routes, or when lifespan events need to initialize singletons like connection pools or ML models before the app serves traffic. Third, they should propose a hybrid: the container or factory builds the application graph during startup, and a thin Depends wrapper retrieves the singleton or constructs the request-scoped wrapper from the container. Fourth, they must name concrete trade-offs: FastAPI Depends is implicit and hard to unit test in isolation because it requires a running route context, while a formal container adds import complexity and indirection but enables explicit graph validation and easier testing.

COMMON WRONG ANSWERS: A major red flag is recommending Depends for every layer including pure business services with no teardown logic, which scatters construction logic across route signatures and creates brittle coupling to the framework. Another mistake is claiming that Depends replaces a DI container entirely; it lacks transitive dependency resolution, named scopes, and lifecycle hooks for true singleton management. Candidates who ignore testing friction or who suggest global variables for shared state also signal weak architectural judgment.

LIKELY FOLLOW-UPS: The interviewer may ask how you would test a service that depends on a repository without spinning up the full FastAPI app. They might also ask how you would handle circular dependencies in a large service graph, or how to share a single heavy object across workers without recreating it per request.

ONE CONCRETE EXAMPLE: Imagine an OrderService that depends on a PaymentGateway and a NotificationClient. With pure Depends, every route that needs OrderService must also declare PaymentGateway and NotificationClient in its signature, creating noisy transitive coupling. Instead, you bootstrap a container in the lifespan event: it creates one PaymentGateway singleton and one NotificationClient singleton. Then a single Depends callable pulls OrderService from the container per request, or the container builds a request-scoped OrderService if needed. This keeps route signatures clean and lets you instantiate OrderService directly in unit tests by passing mocked collaborators to its constructor.