Request-Response Pattern
Explore the request-response pattern to understand its synchronous communication model in system design. Learn its mechanics, real-world applications, and operational trade-offs. This lesson helps you identify when to use request-response or switch to asynchronous patterns for better scalability and resilience.
A client sends a POST request to an Order Service to place a new purchase. The client thread blocks, waiting for confirmation. Two seconds pass. Five seconds. Ten. The response never arrives. Meanwhile, the user stares at a spinning loader, and upstream services that depend on the order status begin queuing their own blocked calls. This scenario is the most common failure mode in synchronous distributed systems.
In the previous lesson on SOA, every service interaction we explored (providers publishing contracts, consumers discovering and binding to endpoints) relied on a single underlying communication primitive. That primitive is the request-response pattern, the synchronous model where a client sends a request and waits for the server’s reply before proceeding. This lesson dissects its mechanics, walks through real-world use cases, exposes its limitations under load, and identifies when asynchronous alternatives are the better architectural choice. Understanding request-response deeply is essential groundwork before we explore the publish-subscribe pattern in the next lesson.
Mechanics of the request-response model
The request-response life cycle begins when a client constructs a message containing a method (GET, POST, PUT), headers (authentication tokens, content type), and an optional payload. This message travels over a transport protocol, typically HTTP on top of TCP, to reach the server. The server parses the request, executes the corresponding business logic, and returns a structured response containing a status code, response headers, and a body.
Connection and serialization behavior
During this entire cycle, the client thread remains blocked. It cannot perform other work until the response arrives or a configured timeout fires. This blocking behavior is the defining characteristic that separates synchronous from asynchronous communication.
Connection management directly affects latency. Short-lived connections require a full TCP handshake (and TLS negotiation for HTTPS) on every call, adding measurable overhead. ...