Software architecture · Level 4: Communication and integration · Module 19 of 46

Synchronous vs asynchronous

Every arrow between two services is either a question you wait on, or a note you leave and move on from. That one choice decides how fast the user gets an answer, whether one slow service slows everything, and how hard it is to know what state the system is in. Most architectures need both kinds, chosen arrow by arrow. This module shows how to choose, and the patterns that make asynchronous communication manageable.

1. The idea

Ordering coffee. At a counter you order, wait and watch it being made (synchronous): simple, and you know exactly when it's ready, but the queue stops while your latte is steamed. In a busy café you order, get a number and sit down (asynchronous): the queue keeps moving and baristas work in parallel, but you need a way to hear your number called, and the café needs a way to tell you they've run out of oat milk after you sat down.

	Synchronous (request/response)	Asynchronous (messages, events)
The caller	Waits for the answer	Continues; the answer, if any, comes later
Both sides up?	Must be, at the same moment	No: messages wait in the broker
Latency the user feels	Sum of every call in the chain	Only the synchronous part
Consistency	Immediate: the caller knows the result	Eventual: the result arrives later
Error handling	An exception or status code, right now	Dead-letter queues, compensations, notifications
Typical tools	REST over HTTP, gRPC	Queues and topics (RabbitMQ, Kafka, SQS), webhooks

REST, gRPC and messaging

REST over HTTP with JSON is universal, human-readable and easy to debug: the default for public APIs. gRPC uses HTTP/2 and compact binary Protocol Buffers, with typed contracts generated from one definition and support for streaming: faster and stricter, popular between internal services. Messaging isn't a faster RPC: it changes the conversation, from "do this and tell me" to "this happened" or "do this when you can".

Three asynchronous conversation patterns

Fire and forget: send and never expect an answer (log an analytics event).
Async notification: start work, and the other side notifies you when it's done (a webhook, an event, a push message), instead of you polling.
Request/reply over messaging: send a request message with a reply-to queue and a correlation ID; the answer arrives on your reply queue, matched by that ID.

2. How it works

Request/reply over messaging

Two prices are requested at almost the same time. The replies come back in the opposite order. Watch why the correlation ID matters.

Polling vs async notification

A user exports a large report that takes 40 seconds to build. Watch two ways for the browser to find out it's ready.

3. Try it yourself

Sync or async, arrow by arrow

Checkout talks to six services. Choose synchronous or asynchronous for each, and watch what the customer waits for, how available checkout is, and what each async choice costs.

Each service's latency and availability are illustrative; asynchronous calls go through a message broker assumed 99.99% available, and add nothing to the customer's wait.

4. Trade-offs

Simplicity vs resilience

Synchronous code reads top to bottom and fails loudly. Asynchronous flows survive outages and absorb bursts, and spread one business action across several places in the code.

Knowing now vs knowing later

If the caller can't continue without the answer (the price, whether the card was accepted), call synchronously. If it can show "pending" and update later, go async.

REST vs gRPC

REST is universal and easy to inspect; gRPC is faster, typed and supports streaming, but needs tooling on both sides and is awkward in browsers. Many systems use REST at the edge and gRPC inside.

Polling vs notification

Polling is simple and stateless but wastes requests and adds delay; notifications are efficient and immediate but need the receiver to be reachable and the sender to retry.

5. In real projects

Decide per arrow, not per system. A typical checkout calls pricing and payment synchronously (the customer needs those answers) and sends email, analytics, loyalty points and warehouse notifications asynchronously.

Make "pending" a first-class state. Once part of a flow is asynchronous, the user may see an order that isn't confirmed yet. Design the screens, emails and support tools for that state, and for the failure that arrives later.

Timeouts on every synchronous call. A call without a timeout can hang a thread forever. Set timeouts below the caller's own deadline, and decide what happens when they fire (Module 22).

Say it in the interview

Two-sentence answers

"When synchronous, when asynchronous?" Synchronous when the caller can't continue without the answer; asynchronous when it can carry on and learn the result later. I decide arrow by arrow.
"How does request/reply work over a queue?" The request carries a reply-to queue and a correlation ID; the responder sends its answer to that queue with the same ID, and the requester matches replies by ID.
"REST or gRPC?" REST for public and browser-facing APIs; gRPC between internal services when performance, strict contracts or streaming matter.

Red flags interviewers notice

Everything synchronous, in a long chain, with no timeouts.
Everything asynchronous, including the price the customer must see.
No answer to "what does the user see while it's pending?"

6. Remember it

Memory hook: "Wait only for what you need to show"If the next screen needs the answer, wait for it. Everything else is a note left for later.

How this hook works: what "wait only for what you need to show" means

What the slogan means, phrase by phrase

"Wait only": Synchronous calls are a cost: latency and coupled availability.
"for what you need to show": Pay that cost only when the user or the next step truly needs the answer now.

Why this picture fits: the café gives you a number because nobody needs to stand at the counter while milk steams; you only wait to pay.

The story → the concept

Café	Communication
Paying at the counter	A synchronous call (payment)
Your order number	A correlation ID
"Number 47!"	Async notification
Walking up to ask "is it ready?"	Polling

The trap it saves you from

Making the customer wait for an email to be sent.

7. Common mistakes

Synchronous chainsCheckout waiting on six services in a row: the slowest and least available one sets the pace for all.

Replies without correlation IDsReplies arrive in any order; without an ID, a caller can pick up someone else's answer.

Aggressive pollingThousands of clients polling every second for a job that takes a minute. Notify, or poll with backoff.

Forgetting the late failureAn asynchronous step that fails after the user was told "done" needs a compensation and a message to the user.

8. Design exercise (30 minutes)

Label every arrow (10 min). Draw one user-facing workflow you know and mark each call sync or async.
Challenge three (10 min). For each synchronous call, ask: does the next screen need this answer? Move the ones that don't.
Design "pending" (10 min). For one async step, write what the user sees before, during and after, including when it fails.

9. Self-check quiz

Why does request/reply over messaging need a correlation ID?

Replies can arrive in any order; the ID ties each one to its request.

The product page must show the current price. Sync or async?

Wait only for what you need to show.

Sending the order confirmation email: sync or async?

Nobody needs to wait for it; an email outage shouldn't fail checkout.

What is async notification?

A webhook, event or push message replaces polling.

Where does gRPC fit best?

Binary, HTTP/2, generated clients: great inside, awkward for browsers and partners.

10. Go deeper

Resource	Time	Why
Request-Reply and Correlation Identifier (Hohpe and Woolf)	15 min	The two patterns behind request/reply over messaging.
gRPC core concepts	20 min	Service definitions, the four call types and streaming.
Software Architecture: The Hard Parts	book	Communication, consistency and coordination as linked choices.