Async & messaging: free-recall review
Free-recall prompts across the async unit. Answer each in your own words first — including the mechanism and the failure mode — then reveal the model answer and compare.
Retrieval beats re-reading. For each prompt, say or write a full answer from memory — the mechanism and the failure it prevents — before you open the model answer. The effort of reconstruction is what makes delivery semantics, the outbox, and the backlog trap stick.
Reconstruct the unit’s spine without looking back: what a queue decouples and what it costs, why exactly-once is effectively-once, how a log differs from a queue, the two coordination styles, how the outbox defeats the dual write, and why an unbounded queue is a latent disaster.
- 01What does a message queue decouple, and what does the decoupling cost you?
- 02Explain at-least-once vs at-most-once and why exactly-once is really effectively-once.
- 03How does a log differ from a queue, and what does that enable?
- 04Define choreography vs orchestration and the rule of thumb, and what event sourcing/CQRS add.
- 05What is the dual-write problem, how does the outbox solve it, and why is eventual consistency a UX problem?
- 06Why is an unbounded queue a latent disaster, and what restores the feedback loop?
If you could reconstruct each answer from memory, you hold the unit’s spine. A queue decouples producer and consumer in time, converting a synchronous availability dependency into an asynchronous latency one — paid for in delivery semantics: at-least-once (no loss, duplicates) is the safe default, and exactly-once is effectively-once via idempotency + dedup, run by the visibility timeout, DLQ, and per-key ordering. Pub/sub fans out, and a log differs from a queue by retaining messages with per-consumer offsets, making replay/backfill first-class. Multi-step flows are choreography (decoupled, simple) or orchestration (a saga with process state and compensations, for complex flows), with event sourcing/CQRS riding a retained log. The outbox defeats the dual-write problem by making the state change and the event one local transaction plus an async relay (never lost, possibly duplicated → idempotent consumers), and the resulting eventual consistency is a UX problem. Finally, every queue needs a bound, or it launders a brief stall into a long backlog; you bound, shed, rate-limit, and alarm on lag. The thread: at this depth, you name the tradeoff before adding the component.
Something unclear?
Ask a question about this lesson. Questions are anonymous and go straight to the author to make the lesson better.