Idempotency in event-driven systems
handling at-least-once delivery.
idempotency means repeated processing yields the same end state; it matters because messages get redelivered; achieve it with idempotency keys and conditional writes.
assuming exactly-once.
What's really being asked
This checks whether you understand at-least-once delivery and can design consumers that tolerate duplicates without corrupting data, a foundational event-driven skill.
The full answer
Idempotency means processing the same event one or many times leaves the system in the same final state. It matters because queues, streams, and webhooks almost always guarantee at-least-once, not exactly-once, delivery: network retries, visibility-timeout expiry, and consumer crashes all cause the same message to be delivered again. To design for it, attach a stable idempotency key derived from the event, such as an order ID or a producer-supplied UUID. Before performing side effects, check a durable dedup store keyed by that ID; if it has been seen, skip or return the prior result. Use conditional writes, for example insert-if-not-exists or compare-and-set, so the database itself rejects duplicates. Prefer naturally idempotent operations such as setting a field to an absolute value over relative mutations. Make the dedup record and the side effect atomic wherever possible.
The mistakes people make
Assuming the platform delivers exactly once. Using blind increments such as balance += amount, which double-charges on redelivery. Relying on application-level locking that does not survive a crash. Treating retries as rare rather than guaranteed. Deduplicating only in memory, which is lost on restart.
What usually comes next
Why is true exactly-once so hard? How do you make the dedup check and the write atomic? What TTL should idempotency keys have? How does idempotency interact with message ordering?
A concrete example
A payment consumer charges a card on each message; redelivery double-charges. Fix it by recording the event UUID in a payments table with a unique constraint, performing the insert and the charge in one transaction. A duplicate insert then fails, the charge is skipped, and the customer is billed exactly once regardless of how many times the message is delivered.
Interview question
A consumer runs balance += amount per message under at-least-once delivery. Why is this dangerous and what fixes it?
- a.Switch to a larger instance size
- b.Nothing; queues always deliver exactly once
- c.Increase the visibility timeout to stop all retries
- d.Redelivery double-applies the increment; use an idempotency key with a conditional writeCorrect
Why? this is the answer
At-least-once delivery means duplicates occur, so blind increments double-apply. Recording an idempotency key and using a conditional write makes reprocessing a no-op. Timeouts and instance size do not eliminate redelivery.
Just read this? Test yourself on what you have been reading.
Read the original → cloud.google.com
- #serverless
- #idempotency
- #event-driven
- #reliability
- #messaging
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on serverless — each one lists the topics its interview covers.
See open roles