Request-response communication pattern
In request-response communication, a client sends a request directly to a server, and the server sends a response back to the client. Each exchange is a single round trip: one request in, one response out. The client initiates every exchange, so request-response is a pull architecture — the server only speaks when spoken to.
Request-response is the canonical synchronous communication pattern. The client issues a request and then waits for the response before proceeding, which couples the two sides in time: the client cannot make progress until the server has replied. This temporal coupling is the defining cost of synchronous request-response, and the reason asynchronous alternatives are preferred for work that does not need an immediate answer.
The pattern’s strength is simplicity. Each request is self-contained, so a server need not remember anything about previous requests to handle the next one. This makes request-response a natural fit for stateless designs and for horizontal scaling behind a load balancer. It is also easy to reason about. The client either gets a response or an error, and the exchange is over.
The matching weakness is that the server cannot initiate an exchange. Anything that requires the server to push data to the client — live updates, notifications, streaming — has to be built on top of request-response with techniques like long polling, or replaced with a push mechanism such as Server-Sent Events, WebSockets, or webhooks.
There is also an asynchronous request-response variant, in which the client issues a request but does not block waiting for the reply. The server responds later, through a callback or a reply queue. The exchange is still one request and one response, but the two sides are decoupled in time. See communication pattern for the broader taxonomy.
Implementations include REST APIs over HTTP, RPC-style protocols such as gRPC, GraphQL (which runs over a single request-response HTTP round trip), and SOAP.