Backend Architecture
Idempotency and retries: free-recall review
Retrieval beats re-reading. For each prompt, reconstruct a full answer from memory before you open the model answer — the effort of pulling the mechanism back is what makes it stick under incident pressure.
Rebuild the unit’s spine without looking back: why exactly-once is an illusion, the four-state key machine, full jitter and retry budgets, the outbox + inbox composition, the concurrency fix, and the observability that turns belief into evidence.
- 01Why is exactly-once delivery an illusion, and how does the unit deliver effectively-once instead?
- 02Walk the four states the server resolves an Idempotency-Key into, with the status code for each.
- 03Why does the request fingerprint matter alongside the key, and what fails silently without it?
- 04Give the full-jitter backoff formula, explain why jitter is non-negotiable, and say why a per-request retry cap is not enough.
- 05Why does any 'write DB then publish to broker' design fail, and how do outbox + inbox fix it?
- 06Two concurrent requests share an idempotency key. Why is SELECT-then-INSERT unsafe, and what is the production-grade store?
If you reconstructed each answer, you hold the unit’s spine: exactly-once is an illusion, so you build effectively-once from at-least-once plus dedup; one key per operation resolves to new / 409 / replay / 422, with the fingerprint guarding against silent loss; retries use full jitter, honour Retry-After, retry only 5xx, and live under a fleet retry budget; the dual-write is closed by outbox atomicity plus an at-least-once relay plus an idempotent inbox; concurrent key creation is made atomic with ON CONFLICT DO NOTHING RETURNING; and the durable store must survive a crash because a lost key is a double charge.