A Django project has mostly sync views plus a few async views that call slow external APIs; should you serve it with WSGI or ASGI?

## Two serving modes, one codebase Every Django project has both entry points: `wsgi.py` for WSGI servers and `asgi.py` for ASGI servers. Views may be sync (`def`) or async (`async def`) under either one; Django adapts whichever side does not match. The real question is which mode makes *this mix* of views cheap to run. ## What each mode does with the views | Aspect | Served with WSGI | Served with ASGI | |---|---|---| | sync view | runs directly on the worker thread | adapted into a thread with `sync_to_async` | | async view | runs in its own one-off event loop per request | runs on the server's event loop | | concurrency inside one async view | yes: `asyncio.gather()` overlaps upstream calls | yes | | one worker serving many slow requests at once | no: the worker is busy until the view returns | yes, if the whole middleware chain is async-capable | | streaming, long-polling, server-sent events | works but ties up a worker per connection | the intended use | | persistent DB connections (`CONN_MAX_AGE` > 0) | normal | the docs say to disable them and use pooling | Django's async documentation sums up WSGI plainly: async views work, with a small per-request adaptation cost, but *without the ability to have efficient long-running requests*. ## The cost of mixing Switching between sync and async costs something each time. The Django 6.1 docs put it at **tens of microseconds** per call on the in-request ASGI path — rarely visible against a request measured in milliseconds, but it adds up in tight loops and under thread contention. Two rules follow: - **Middleware decides the ceiling.** If all middleware and views are sync, Django under ASGI switches once, before the middleware stack. If a **sync middleware sits between the ASGI server and an async view**, Django runs that middleware in its own thread and holds the thread for the request, which caps exactly the concurrency ASGI was chosen for. - **Django's bundled middleware supports both modes; third-party middleware may not.** Turn on debug logging for the `django.request` logger and look for *Asynchronous handler adapted for middleware* to see which ones are being adapted. Sync ORM work under ASGI runs in thread-sensitive mode: calls within one request serialise on that request's worker thread, while concurrent requests each get their own. That mirrors Django's connection-per-thread model, which is why the database side needs attention too. ## A decision checklist 1. **What do the async views wait on?** A few upstream calls gathered and returned in well under a second: WSGI is fine and operationally simpler. Streaming responses, long-polling or many seconds of upstream waiting: ASGI. 2. **Is the middleware chain async-capable end to end?** If not, fix or replace the sync pieces before counting on ASGI concurrency. 3. **How are database connections managed?** Under ASGI, set `CONN_MAX_AGE = 0` and use a pool — the PostgreSQL `pool` option since Django 5.1, or an external pooler — sized for concurrent requests. 4. **Does the team have async discipline?** Blocking calls inside `async def` code stall every request on that event loop; Django guards its own async-unsafe parts, but third-party libraries may not. 5. **Measure.** Django's docs recommend load-testing both modes on your own code; a purely sync project can see small gains under ASGI, but the general guidance is to enable ASGI when you have async code that needs it. ## Running both Because the two entry points share one codebase, a common middle path is to keep the bulk of traffic on a WSGI deployment and route the few streaming or long-waiting paths, at the reverse proxy, to an ASGI deployment of the same project. It costs a second deployment but keeps sync-heavy traffic on the simpler model. ## What interviewers listen for That the candidate knows async views *work* under WSGI and what they lose there, that sync middleware undermines an ASGI stack, and that the database connection strategy changes with the serving mode.