How does the request lifecycle work in Django?

Question

IT Interview Practice · Accepted Answer

In Django, a request is handled by the **WSGI/ASGI handler**, wrapped by a stack of **middleware**, routed by the **URL resolver** to a **view**, and turned into an `HttpResponse` that flows back out through the same middleware in reverse.

## The stages

```
Web server ──▶ WSGI/ASGI handler  (creates HttpRequest)
   ▼
Middleware — request phase        (top → bottom: __call__ before get_response)
   ▼
URL resolver (urls.py)  ── match path → view + kwargs
   ▼
Middleware — process_view hook
   ▼
View (function / class-based)  ── your logic, returns HttpResponse
   ▼
Middleware — response phase        (bottom → top: after get_response)
   ▼
HttpResponse ──▶ client
```

1. **Handler** — the WSGI (sync) or ASGI (async) handler builds an `HttpRequest` from the environ/scope.
2. **Middleware, request phase** — each middleware's code *before* `get_response()` runs top-to-bottom (`SecurityMiddleware`, `SessionMiddleware`, `AuthenticationMiddleware`, CSRF, …). Any of them can short-circuit and return a response early.
3. **URL resolution** — `ROOT_URLCONF` patterns are matched against the path to select a view and capture kwargs.
4. **`process_view`** — a middleware hook that runs just before the view is called.
5. **View** — your function- or class-based view runs, typically querying models and rendering a template, and returns an `HttpResponse`. Exceptions trigger `process_exception`.
6. **Middleware, response phase** — code *after* `get_response()` runs bottom-to-top, letting middleware modify the outgoing response (headers, compression).
7. The `HttpResponse` is streamed back to the server and client.

```python
# middleware.py
class TimingMiddleware:
    def __init__(self, get_response):
        self.get_response = get_response

def __call__(self, request):          # 2. request phase (before)
        request.started = time.monotonic()
        response = self.get_response(request)  # calls the next layer / view
        response["X-Time"] = "..."         # 6. response phase (after)
        return response

# urls.py  → 3. routing
urlpatterns = [path("items/<int:pk>/", views.item_detail)]

# views.py → 5. view
def item_detail(request, pk):
    return render(request, "item.html", {"item": Item.objects.get(pk=pk)})
```

## Why it matters

Django's request/response cycle is middleware-centric, so most cross-cutting behavior — auth, sessions, CSRF, security headers, caching — is implemented as ordered middleware. Understanding that request-phase code runs top-down and response-phase code runs bottom-up (and that ordering in `MIDDLEWARE` matters) is essential to placing your own middleware correctly, debugging why a `403`/redirect happens before your view, and knowing where to hook logic without touching every view.

The stages

Why it matters

Related questions