the request-reply pattern

Most networked conversations follow the rhythm of a question and an answer: one side asks, the other responds, and they take turns. You ask a librarian a question and wait for the reply before asking the next. This back-and-forth is the request-reply pattern, the most common way application protocols are structured — one party sends a request, then waits for a single matching reply before moving on.

HTTP is the textbook example: the client sends one request and gets back exactly one response, then can send another. SMTP, FTP commands, and DNS queries all follow this turn-taking shape too. The defining feature is the pairing — each reply belongs to a specific request, and the requester usually blocks (waits) until the reply arrives. This makes the model easy to reason about: at any moment you know exactly which question you are answering. It also makes failure handling clear — if no reply comes within a timeout, the requester knows something went wrong and can retry or give up.

Request-reply is not the only style, and recognising its limits matters. Its weakness is latency under load: if each request must finish before the next reply, a slow operation stalls progress (this is the head-of-line problem persistent HTTP/1.1 connections hit). The alternative is streaming, where data flows continuously without a one-question-one-answer rhythm — a live video, a stock-price feed, or a chat connection pushes a steady stream of messages, and either side may speak at any time. A third style is publish-subscribe (used by MQTT and similar), where senders publish messages and any number of interested subscribers receive them, with no direct reply at all. Picking request-reply versus streaming versus publish-subscribe is one of the first and most consequential decisions in designing an application protocol.