Introduction

WSGI is synchronous because its interface is built around a simple call-and-return contract. The server calls the application for one request, waits while the application does its work, and only moves forward for that request when the response iterable is produced.

The WSGI Contract Is Blocking

A WSGI application is just a callable that receives environ and start_response, then returns an iterable of response bytes. There is no built-in await, coroutine protocol, or event-loop handshake in that interface.

1import time
2
3def app(environ, start_response):
4    time.sleep(2)
5
6    status = "200 OK"
7    headers = [("Content-Type", "text/plain; charset=utf-8")]
8    start_response(status, headers)
9    return [b"hello from WSGI"]

This code looks simple because it is simple. While time.sleep(2) runs, that worker is blocked. The WSGI server cannot continue that request until the function resumes and returns response data.

The same thing happens with slow database queries, file reads, or HTTP calls to other services. A WSGI app can do many things internally, but the interface itself is synchronous.

Concurrency Comes From More Workers, Not From WSGI Itself

A WSGI deployment can still handle many users, but it usually does that by running multiple worker processes or threads. Each worker handles requests one at a time in the synchronous WSGI style.

That means concurrency exists at the server level, not because the app interface is non-blocking. For example, Gunicorn may run several workers, and each worker may serve a different request. But inside one worker, a blocking operation still occupies that worker until it finishes.

This is an important distinction:

• WSGI apps can be deployed concurrently
• The WSGI protocol itself is still synchronous

Why ASGI Feels Different

ASGI was designed to support asynchronous Python workloads such as websockets, long-lived connections, and non-blocking I/O. A typical ASGI handler can use async def and await, which lets the event loop switch to other tasks while one request is waiting on I/O.

By contrast, classic WSGI expects a normal callable and a normal response flow. It has no native way to suspend one request handler and resume it later through the interface itself.

What Synchronous Really Means in Practice

Synchronous does not mean "always slow." Many WSGI applications perform very well when requests are short and worker counts are tuned properly. It simply means the request lifecycle is modeled as a blocking sequence of steps inside each worker.

That model is often perfectly fine for traditional server-rendered pages, CRUD applications, and APIs with predictable request times. It becomes more limiting when you need high connection counts, streaming-style protocols, or many simultaneous slow I/O operations.

It is better to think of WSGI as simple and blocking rather than as inherently weak. The model still works well when the workload matches it.

Common Pitfalls

• People often confuse "multiple workers" with "asynchronous interface." They are not the same thing.
• A WSGI app can call async libraries indirectly, but the WSGI boundary itself remains synchronous.
• Blocking I/O inside a WSGI worker ties up that worker until the operation finishes.
• WSGI is still useful for many applications, so synchronous does not automatically mean obsolete.

Summary

• WSGI is synchronous because the server calls the app and waits for the response in a blocking request cycle.
• The interface does not include native coroutine or event-loop semantics.
• Concurrency with WSGI usually comes from multiple threads or processes, not from non-blocking request handling.
• ASGI was created to solve the kinds of workloads that do not fit WSGI's synchronous model well.