How does FastAPI cache dependencies within a single request?

WHAT THIS TESTS: Whether you understand FastAPI's dependency injection resolution model beyond basic decorator usage. Specifically, it checks if you know that dependencies are resolved per request and that FastAPI avoids redundant work by caching the result of a dependency after its first execution within a single request's dependency tree. The interviewer wants to see that you grasp the difference between declaration and execution, and that you understand the framework optimizes dependency resolution automatically without manual intervention.

A GOOD ANSWER COVERS: First, state that by default FastAPI executes a dependency once per request and caches the return value for reuse within that request's dependency tree. Second, mention that this behavior is controlled by the use_cache parameter on Depends which defaults to True. Third, clarify that the cache is strictly scoped to a single request and is not shared across concurrent or subsequent requests, so each incoming request gets its own fresh resolution. Fourth, note that you can force re-execution by setting use_cache=False when a dependency is not idempotent or must run fresh each time it is injected, such as for certain audit or timestamp operations.

COMMON WRONG ANSWERS: A major red flag is claiming the dependency runs every time it is declared in the tree. Another mistake is asserting the cache is global across all requests or threads. Some candidates forget that caching only applies within one request lifecycle and does not persist between requests. Suggesting manual memoization or singleton patterns instead of FastAPI's built-in request-scoped mechanism is also a sign of weak framework knowledge. Finally, confusing dependency caching with Python default argument mutability shows a shallow understanding.

LIKELY FOLLOW-UPS: An interviewer might ask when to set use_cache to False and what performance trade-offs that creates. They may ask how this interacts with async dependencies and the event loop. They might probe whether caching differs for dependencies in path operation decorators versus function parameters. You could be asked how caching affects side effects like logging or auditing, or whether it can hide bugs in non-idempotent dependencies. Finally, expect a question about how to test or verify that a dependency executes only once per request.

ONE CONCRETE EXAMPLE: Imagine a get_current_user dependency that queries a database to validate a JWT and fetch a user record. If both a path operation function and a sub-dependency require get_current_user, FastAPI calls it once during request resolution, caches the user object, and injects the same instance into both places. This means one database query per request instead of two. If use_cache were set to False, the database query would execute twice in the same request, adding unnecessary latency and load. If the cache were mistakenly thought to be global, you might accidentally serve one user's data to another, which is why understanding request-scoped isolation matters.