Synchronous vs asynchronous communication

Checkout waits on five services in turn, each up 99.9 % of the time, so it fails whenever any one of them is down: about 216 minutes of failed orders a month. A call is synchronous when the caller waits for the answer before it does anything else, and asynchronous when it hands the work over, to a queue or to a job that reports back, and carries on.

Wait when the caller cannot continue without the answer and the callee is fast and dependable, as with reading a price or authorising a payment. Hand the work over when it is slow, can safely happen later, or must not take the caller down when it fails, as with emails, reports and search indexing. A sound default for user-facing writes: keep the user waiting only until the change is durably committed, and do everything after the commit asynchronously.

Waiting couples the caller to every callee

A synchronous call creates temporal couplingtemporal coupling: The dependence a synchronous call creates between a caller and its callee: both must be up, and fast, at the same moment. Along a chain of such calls, availabilities multiply and latencies add.: the caller and the callee must both be up, and fast, at the same moment. The coupling compounds along a chain, because every service the request waits on is a hard dependencyhard dependency: A part that every request needs, so the service fails whenever it does. Hard dependencies are in series, and each one lowers the availability the whole service can reach. More in “Availability maths: nines, series and parallel”. If checkout waits on five services in turn and each is up 99.9 % of the time, an order succeeds only when all five are, so its availability is the product of theirs when they fail independently:

"""How available is a request that waits on a chain of services? Each service is up 99.9 % of the time, and
failures are assumed independent (shared causes such as one database make the real numbers worse)."""

MINUTES_A_MONTH = 30 * 24 * 60
EACH = 0.999

print("services the request waits on   available   down a month")
for n in range(1, 7):
    up = EACH**n
    print(f"{n:>29}   {up:>9.2%}   {(1 - up) * MINUTES_A_MONTH:>6.0f} min")

# Asynchronous after the commit: the request needs only the API and the queue; the workers behind the queue may
# be down without failing it (its work waits instead).
up = EACH**2
print(f"\nAPI and queue only (workers behind the queue)   {up:.2%}   {(1 - up) * MINUTES_A_MONTH:.0f} min")

services the request waits on   available   down a month
                            1      99.90%       43 min
                            2      99.80%       86 min
                            3      99.70%      129 min
                            4      99.60%      173 min
                            5      99.50%      216 min
                            6      99.40%      259 min

API and queue only (workers behind the queue)   99.80%   86 min

Five services at 99.9 % leave checkout at 99.5 %: about 216 minutes of failed orders a month instead of 43. Their latencies add up along the chain too, so every callee’s slow moments become the shopper’s wait. Asynchronous communication breaks the chain at the commit: the request needs only the API and a durable queue, and the work behind the queue waits, instead of failing, while its service is down. Follow one order through both designs during a 30-second email outage:

With a queue in front of the email service, a 30-second email outage becomes 30 seconds of late emails instead of 30 seconds of failed orders. Both designs side by side, and three ways to learn the outcome:

The ways to communicate, by name:

• Synchronous request-response: the caller sends a request and blocks until a reply or a timeout.
• Asynchronous request-replyasynchronous request-reply: An API pattern for work that outlives a request: the server answers 202 Accepted at once, with the URL of a status resource that the client polls until the work is done.: the server answers 202 Accepted at once, with a status URL the client polls.
• Callbacks: the server calls the client back, for example through a webhook, when the work is done.
• Queues: a producer leaves a message, and one of several consumers processes it when it is ready.
• Publish-subscribepublish-subscribe: A messaging style in which a producer publishes an event and every subscriber receives its own copy and acts on it in its own time, without the producer knowing who listens.: a producer publishes an event, and every subscriber receives it and acts in its own time.

Asynchronous communication has its own costs: it trades an outage for a delay, and adds duplicate deliveries, messages out of order and failures that nobody is waiting to see.

Measuring the coupling over one simulated day Pro: opens with a Pro, Premium or Ultimate pass