What are startup and shutdown events in FastAPI?

WHAT THIS TESTS: This question checks whether you understand the application lifespan boundary in ASGI applications and can distinguish one-time initialization from per-request logic. Interviewers want to see that you know where to place expensive setup and cleanup code so it does not run on every request.

A GOOD ANSWER COVERS: First, define startup as logic that executes exactly once before the application begins receiving requests, and shutdown as logic that executes exactly once after the application finishes handling requests. Second, give concrete use cases: startup is commonly used to create a database connection pool, initialize an HTTP client session, or load a large machine learning model into memory; shutdown is used to close that pool, flush telemetry buffers, or release file handles gracefully. Third, mention that FastAPI now prefers the lifespan async context manager over the older startup and shutdown event decorators because the context manager naturally pairs setup and teardown and is easier to test. Fourth, note that these hooks are application-level, not route-level, and that they should be kept non-blocking or async when possible to avoid delaying server readiness.

COMMON WRONG ANSWERS: A major red flag is describing startup or shutdown as per-request middleware or route dependencies. Another mistake is suggesting heavy synchronous I/O inside a startup event without acknowledging that it blocks the event loop and delays the server from accepting traffic. Some candidates also forget to mention shutdown cleanup entirely, which signals poor operational awareness. Finally, claiming that startup and shutdown events are the modern recommended approach without mentioning their deprecation in favor of lifespan context managers shows outdated knowledge.

LIKELY FOLLOW-UPS: The interviewer may ask how you would test lifespan events, how they differ from dependency with yield, or what happens if a startup event raises an exception. They might also ask how sub-applications handle lifespan events or how you would manage a shared Redis connection across workers.

ONE CONCRETE EXAMPLE: A practical startup use case is creating an async SQLAlchemy engine and sessionmaker when the app boots so that every route can reuse the same pool instead of creating connections per request. The matching shutdown use case is calling engine.dispose() to close all database connections cleanly after the last request is served, preventing connection leaks during deployments or container restarts.