Synchronous and Asynchronous Communication: Request–Response, Command and Event

Objectives

By the end of the lesson, you can distinguish synchronous and asynchronous cooperation and the models of request–response, command and event, and you can name the seven aspects for comparing communication methods.

Why is it needed?

Communication methods (REST, that is Representational State Transfer; message queue, WebSocket, polling…) differ along many aspects. If the aspects are named in advance, the methods can be compared, and the choice is not about fashion. Three separate questions should always be kept apart: what is the meaning of the interaction (request, command, event), what transport carries it, and what temporal dependence there is between the parties.

Synchronous and asynchronous

In synchronous cooperation the caller waits for the response before moving on. It makes things easy to follow, but the availability and latency of the callee become part of the caller's path. Waiting does not necessarily block an operating-system thread: even with asynchronous I/O the logical dependence remains if the business operation cannot continue without the response. The language-level async is therefore not the same as asynchronous service communication.

In asynchronous cooperation the execution of the sender and the receiver is separated in time: the sender does not wait for the result. An intermediary can take over the message even if the receiver is not running. This reduces direct availability dependence, but new states appear: waiting, in progress, processed and failed messages. Receiving is not the same as processing, and it must also be visible to the user when the result is still pending.

The 202 Accepted status of RFC 9110 is the HTTP expression of this: the request has been accepted for processing, but the processing has not been completed, and the response is "intentionally noncommittal"; the server cannot later send a status code back, so the response describes the current state and points to a status monitor.

Request–response, command, event

Model	Meaning	Addressee	Failure handling
Request–response	The caller asks for the result of an operation	The callee	The caller waits; the result or a state that can be queried later
Command	An intention ("reserve")	A specific executor, who can refuse	The result, or the place of the result, must be known
Event	A fact that happened ("it was reserved")	Anyone interested	The consumer is responsible for its own reaction

An event that the producer sends as an expectation is a disguised command (4.1). The difference between command and event also affects the contract.

The seven aspects: how are methods compared?

The following chapters name the same seven aspects for every communication method:

Aspect	Question
Direction	Is the data flow one-way or two-way?
Initiator	Who starts the message: the client, the server, or a third party?
Connection persistence	New for each request, or kept open?
Latency	How much time passes between the change and its detection?
Load	What cost arises with empty or dense traffic?
Fault tolerance	What happens on interruption: can a message be lost, can it be repeated?
When it fits and when not	What need does it fit, and which does it not?

flowchart LR
  subgraph Sync["Synchronous request–response"]
    R1["REST, RPC, GraphQL (chapter 7)"]
  end
  subgraph Async["Asynchronous, with an intermediary"]
    Q["Message queue, pub/sub, webhook (chapter 8)"]
  end
  subgraph Fresh["Updates from the server side"]
    P["Polling, long polling, SSE, WebRTC (chapter 9)"]
    W["WebSocket (chapter 10)"]
  end

The order of the chapters follows the nature of the connection: first the synchronous styles with a new exchange per request, then the message brokers, then the methods that deliver changes from the server side to the client, and finally the persistent, two-way WebSocket.

Streaming

A stream carries more data in one logical flow: it can be from server to client, from client to server, or two-way. In a status-watching stream the elements may be events, while the stream of a file download is a sequence of bytes. Streaming is not automatically an event-driven business architecture. In long streams, interruption, the slow receiver and the resume point must be handled (8.4, 10.4).

Common misconceptions

Statement	Clarification
"Asynchronous code is asynchronous service communication."	Logical dependence on the response may remain.
"With an asynchronous message, acceptance = execution."	Receiving and processing are separate events.
"A command and an event are the same."	One is an intention, the other a fact.
"HTTP can only be request–response."	Event streams and long operations can also be carried over HTTP.

In short

• Synchronous parties wait logically; asynchronous ones are separated in time, with an intermediary.
• Request–response asks for a result, a command an intention, an event reports a fact.
• Receiving is not processing; asynchronous operation has a pending state.
• Methods are compared along seven aspects: direction, initiator, persistence, latency, load, fault tolerance, applicability.

Review questions

1. Why is the async keyword not enough for asynchronous cooperation?
2. What is the difference between a command and an event?
3. Along which seven aspects is it worth comparing communication methods?

Learning resources

• RFC 9110, 15.3.3: 202 Accepted — the HTTP expression of accepted but not completed processing.
• What do you mean by "Event-Driven"? (Martin Fowler) — event and command, disguised commands.