awesome-everything RU
↑ Back to the climb

Queues, Streams, Eventing

Queues capstone: free-recall review

Crux Free-recall prompts spanning the whole queues track. Answer each in your own words from memory first, then reveal the model answer and compare.
Your altitude — climbing toward senior
ZeroJuniorMiddleSenior
You are at senior altitude — in orbit
◷ 14 min

Retrieval beats re-reading. Each prompt asks you to reconstruct one seam of the order pipeline from memory — say or write a full answer before you open the model answer. The effort of recall is what welds the track’s lessons into one design you can defend in a review.

Goal

Reconstruct the pipeline’s spine without looking back: outbox atomicity, CDC’s slot risk, per-key ordering, the at-least-once-plus-idempotency contract, retry budgets and the DLQ, and the eventual-consistency UI.

Recall before you leave
  1. 01
    Walk an order event through all six hops of the pipeline and name the guarantee and the defence at each.
  2. 02
    Why is idempotency, not exactly-once delivery, the invariant that holds the whole pipeline together?
  3. 03
    Both the outbox and CDC give at-least-once delivery. Explain how they compose and why CDC's replication slot is the most dangerous piece in the whole system.
  4. 04
    Where does per-key ordering live in the pipeline, and name three ways it silently breaks in production.
  5. 05
    A transient failure and a poison message both fail the payment consumer. Explain why they need different handling and how the retry budget plus DLQ separate them.
  6. 06
    Two metrics together — rising consumer lag and a filling dead-letter queue — describe one failure. Explain it and where observability has to live across the pipeline.
Recap

If you reconstructed each answer from memory, you hold the track’s spine: the outbox makes the write and its event atomic in one local transaction; CDC ships those rows at-least-once and its replication slot is the loaded gun you must alert on and cap; the topic preserves per-key order by keying on order_id, and that order breaks when you repartition, when retries and DLQ replays reinsert out of band, or when a non-idempotent producer reorders; the consumer group delivers at-least-once by committing after processing, so handlers must be idempotent; transient failures retry against a budget while poison messages go to the DLQ; and the UI tells the truth about the consistency window. Idempotency is the thread, and observability lives at the seams — a correlation id end to end, lag watched by trend, and alarms on DLQ depth and slot lag.

Continue the climb ↑Queues capstone: code and config reading
shortcuts expand
search
K
prev piece
k
next piece
j
cycle tier
t
this menu
?
sources3
expand
  1. 01
  2. 02
  3. 03

Trademarks belong to their respective owners. Editorial reference only.