Checkpoint: Real-time & Async Communication

You've Got the Whole Toolbox — Now Choose

This section handed you a lot of ways to move data between machines: asking repeatedly (polling), a two-way live connection (WebSockets), one-way server push (SSE), cross-company callbacks (webhooks), peer-to-peer media (WebRTC), and then the async side — synchronous calls made safe, queues that absorb bursts, logs versus brokers, pub/sub fan-out, and the honest truth about delivery guarantees.

Knowing what each is isn't the skill. The skill is reaching for the right one when a real feature lands on your desk — and, just as often, not over-engineering a simple thing into a live socket. This checkpoint is ten concrete features. For each, you pick the communication style and immediately see whether it holds up, why, and which lesson it came from. Aim for 7 out of 10; anything you miss points you straight back to the lesson worth a second read.

A decision-map infographic titled 'Which way should the bytes flow?' summarizing the real-time and async communication styles from this section as a quick-reference table. The rows, each with a small icon and a one-line when-to-use, are: short polling or fetch-on-load for data that rarely changes; long polling for near-real-time without a persistent socket; WebSocket for low-latency two-way traffic like chat and collaborative editing; Server-Sent Events for one-way server-to-client streams like live feeds and tickers; webhooks for server-to-server push across a company boundary; and WebRTC for peer-to-peer audio and video. Below a divider, a second group covers async and messaging: a synchronous call wrapped in a timeout and retry when you need the answer now; a message queue to absorb a burst and let workers drain at their own pace; a log versus a broker, where a Kafka log is replayable with consumer groups and a RabbitMQ broker deletes on acknowledgement; pub/sub to broadcast one event to many independent subscribers; and delivery semantics, where at-least-once plus an idempotent consumer gives an effectively exactly-once result. A compass in the corner and two axis hints read one-way versus two-way and sync versus async. The takeaway line reads: match the feature to the flow — real-time push, request and reply, or fire and forget. The palette is dark slate with sky-blue real-time styles and emerald async and messaging styles.

Make the Call: Ten Features, Ten Decisions

Read each feature like a ticket you've just been handed. Resist the urge to pick the fanciest option — the right answer is often the simplest one that fits. Choose, read the reasoning, and move on:

A decision checkpoint for the whole section: ten real product features, and for each you choose the right communication style — poll, WebSocket, SSE, webhook, WebRTC, a synchronous call, a queue, a log, pub/sub, or an idempotent consumer. Answer one at a time, get instant right-or-wrong with the reasoning and the lesson it tests, and a running score that either locks the section in or points you at exactly what to revisit.

What You Can Now Do

If those felt natural, you've internalized the section's real payoff — a decision reflex:

Real-time to the browser? Ask which direction. One-way server→client → SSE; two-way and chatty → WebSocket; changes rarely → just poll or fetch; peer media → WebRTC; across a company boundary → webhook.
Service-to-service? Ask do I need the answer now? Yes → a synchronous call with a timeout and retry; no → hand it off async.
Going async? Ask what shape of delivery? Absorb a burst → a queue; replay and many readers → a log; broadcast one event to many → pub/sub; and always assume at-least-once, so make consumers idempotent.

That three-question reflex — which direction, need it now, what shape — is what separates picking a pattern on purpose from cargo-culting whatever you used last time.

Wrapping Up the Section

There's no single "real-time" tool — there's a direction (one-way vs two-way), a timing (sync vs async), and a shape (request/reply, push, or fire-and-forget), and each feature picks its own point in that space.
The most common mistake isn't choosing the wrong advanced tool — it's choosing an advanced tool at all when a plain request would do. Simplicity that fits beats sophistication that doesn't.
Everything async rides on the same honest foundation: messages can be lost or duplicated, so you design for at-least-once and make the effect idempotent.

That closes Real-time & Async Communication. Next up is Caching — the other half of making systems fast: instead of moving work off the request path, you avoid the work entirely by remembering the answer.