Request-Response

Request-response is the simplest way two programs talk to each other over a network. A client opens a connection, sends a message describing what it wants, and then pauses. The server reads that message, does the work, and sends back a single reply. The client unblocks the moment the reply arrives. One request, one response, in that order.

This is the pattern behind almost everything you use on the web. When your browser loads a page, it sends an HTTP GET request and waits for the HTML to come back. When a mobile app fetches your profile, it makes a REST call and waits for the JSON. The defining trait is that the requester expects an answer and ties the answer to the specific request it sent.

Contrast this with one-way messaging (fire-and-forget) where you send a message and never wait, or publish-subscribe where you broadcast an event and many listeners react on their own schedule. Request-response is synchronous in spirit: the caller's next step depends on the callee's answer.

Every request-response system needs a way to match a reply to its original request. Over a single TCP connection that is easy: the response comes back on the same socket. But once you add connection pooling, multiplexing, or async clients, you need correlation. HTTP/2 tags each request with a stream ID so many requests can share one connection and the right responses still get matched. gRPC, which runs on HTTP/2, does the same.

The caller almost always sets a timeout. If the server does not respond within, say, 30 seconds, the client gives up and treats it as a failure rather than waiting forever. This is critical because a network can drop a packet or a server can hang, and a client with no timeout will block one of its threads or connections indefinitely. Real clients pair timeouts with retries and sometimes a circuit breaker.

Status codes carry the outcome. HTTP uses numbers like 200 for success, 404 for not found, and 503 when the server is overloaded. gRPC has its own set such as OK, NOT_FOUND, and DEADLINE_EXCEEDED. The response also carries the payload, usually JSON, Protocol Buffers, or plain bytes, plus headers describing content type and caching rules.

Reach for request-response when the caller genuinely needs the answer before it can move on: reading a user record, validating a login, charging a card, fetching search results. The pattern is easy to reason about, easy to debug (you can replay a single curl command), and supported by every language and framework with zero extra infrastructure.

The cost is coupling in time. The client is blocked and holding resources while it waits, so a slow server directly slows down every caller. If service A calls B which calls C, the total latency is the sum, and any one failure breaks the whole chain. Under load this turns into thread or connection exhaustion, which is why teams add timeouts, bulkheads, and circuit breakers.

When the caller does not need an immediate answer, request-response is the wrong tool. Sending a welcome email, generating a report, or processing a video should go through a message queue or event stream instead, so the request returns instantly and the work happens in the background. A common mistake is making a user wait on an HTTP request while a 20-second job runs synchronously behind it.

Think about checking out on an e-commerce site. Your browser sends POST /orders with the cart contents. The order service receives it, then itself makes request-response calls: one to the inventory service to confirm stock, one to the payment gateway to charge the card, one to the user service to load the shipping address. Each call blocks until it gets a reply.

If the payment gateway returns 200 OK with an approval, the order service writes the order and returns 201 Created to the browser, which then shows the confirmation page. If the gateway times out after 10 seconds, the order service catches it, may retry once, and if it still fails returns a 503 so the browser can show please try again rather than spinning forever.

Notice what stays synchronous and what does not. Confirming payment must block because you cannot show success until the money clears. But sending the confirmation email and updating analytics are fired off to a queue after the response is returned, so the shopper is not kept waiting on work they do not care about.