What are the key responsibilities for Nginx versus Uvicorn?

What's really being asked

This question probes whether you understand the production deployment boundary between a reverse proxy and an ASGI server. Interviewers want to see that you know why FastAPI documentation recommends placing Uvicorn behind Nginx rather than exposing Uvicorn directly to the internet. The core signal is your ability to separate infrastructure concerns like TLS and static files from application concerns like async request handling and Python code execution.

The full answer

A strong answer assigns distinct responsibilities to each layer. Nginx should handle TLS termination and HTTPS certificate management, serve static assets directly from disk without touching Python, buffer slow client connections to free Uvicorn workers, and load balance traffic across multiple Uvicorn worker processes. Uvicorn should handle running the Python ASGI application, managing the async event loop, executing FastAPI path operations, and keeping connections to Nginx over plain HTTP on a local port or Unix socket. You should also mention that Nginx is written in C and handles thousands of concurrent keepalive connections efficiently, whereas Uvicorn workers are single-threaded async processes that should not be tied up waiting on slow network IO from end users.

The mistakes people make

Red flags include suggesting Uvicorn should terminate TLS for public traffic, claiming Nginx should execute Python logic or replace Uvicorn entirely, or stating that Uvicorn alone is sufficient for production because it is fast. Another mistake is omitting slow-client protection or forgetting that static file serving belongs in Nginx, not FastAPI, for performance.

What usually comes next

Interviewers may ask how you would scale Uvicorn workers, whether to use Gunicorn as a process manager in front of Uvicorn, how Unix sockets versus TCP ports affect performance, or how Nginx location blocks route API traffic versus static content. They might also probe how you handle WebSocket connections through Nginx with upgrade headers.

A concrete example

Imagine a deployment on an Ubuntu server. You configure Nginx to listen on port 443 with SSL certificates from Let's Encrypt. Nginx serves images and JavaScript from /var/www/static directly. API requests matching location /api are proxied with proxy_pass to http://127.0.0.1:8000 using keepalive connections and proxy buffering enabled. Uvicorn binds to localhost port 8000 with four workers, running the FastAPI app. If a user on a mobile network uploads a large file, Nginx buffers the upload so the Uvicorn worker can process it immediately rather than waiting for the slow upload to finish.