Top 28 Idempotency Interview Questions
Browse 28 real-world technical and behavioral interview questions about Idempotency. Review scenarios, edge cases, and architectural best practices.
Design a notification system that sends 50 million messages a day across email, SMS and push.
A notification system at 50 million a day is sized by bursts and provider limits, not its average of about 580 a second. Accept with an idempotency key, apply preferences once, fan out to per-channel queues with transactional and bulk lanes, rate-limit each provider, and never fail over blindly on a timeout.
Design a platform that runs agent tasks for hours and pauses for a human to approve risky steps.
Use durable execution. Persist every model output and tool result as a step in a log, so a run resumes on any worker by replaying recorded results instead of asking the model again. An approval wait suspends the run with no thread held, and every tool is idempotent on a run-and-step key.
Design a distributed job scheduler that runs every job once, and on time, even when workers die.
A distributed job scheduler cannot promise exactly-once execution when workers die mid-job, so it promises at-least-once with idempotent jobs. Materialise each firing as a run row, claim it with a lease and heartbeats, judge time by one clock, and key side effects on job id plus scheduled time.
You must ingest all of English Wikipedia every day, and the source does not want to be hammered. What runs, how often, and what do you do about the run that fails at hour six?
Do not re-download Wikipedia daily. Use incremental ingestion: load the published dump once, follow the recent-changes feed, and fetch only the latest revision of each changed page in small, polite batches. Checkpointing each batch behind a revision-guarded write lets a run that fails at hour six resume.
An Android app queues actions while offline. After the process is killed and restarted, some actions sync twice and the user sees duplicate orders. How do you design the fix?
The queue records that work was sent but cannot know whether the server received it, so any crash between sending and recording the acknowledgement replays the action. At-least-once delivery is the only thing a mobile client can guarantee, so the fix is to make the operation idempotent with a client-generated key persisted alongside the queued action, not to try harder to deliver exactly once.
Your services talk through events and one consumer has been down for an hour. What has it missed, and how does it catch up?
A Kafka-style consumer down for an hour has missed an offset range, not necessarily lost data. If retention still covers the gap, it resumes from the committed offset; catch-up needs surplus throughput, idempotent handlers, event-time logic and a plan for retention expiry. Use this event driven answer to show the decision, trade-off, and evidence rather than a memorised definition.
The monthly bill run dies two thirds of the way through and the cycle closes tomorrow. What do you do?
Restart rather than rerun. The run is not a transaction but a sequence of per-account commitments, so each account must be either fully billed or untouched, charge assembly must be deterministic from inputs frozen at cut-off, and quarantining the offending accounts beats missing the cycle.
How would you design a data pipeline you can safely re-run?
Design a safely rerunnable data pipeline by making each output partition a deterministic result of its input partition, overwriting instead of appending, and writing into idempotent sinks that tolerate retries and late events.
How do you design the tools an agent calls?
Give each tool one narrow purpose with a self-describing schema, return failures as structured results the model can act on rather than raising, take an idempotency key on anything that mutates, and put validation and authorisation in the executor because arguments produced by a model are untrusted input.
You own the API test suite for a service from scratch. How do you structure it, and what do you mock?
Separate contract tests, which check shape and backwards compatibility cheaply, from integration tests that exercise real behaviour across real dependencies. Make every test create and own its data so the suite is re-runnable, spend most of your negative cases on authorisation and malformed input.
A fill arrives for an order your system has already marked cancelled. What do you do?
Book the fill. The venue decides what happened, so a fill against a cancelled order means your state was wrong, and the position, risk headroom and client record all have to be corrected from the venue's version. The design fix is to make cancelled a state only the venue can grant.
How do you turn a training script that works on your laptop into a scheduled pipeline?
Split it at points where the intermediate output is worth keeping, make each stage idempotent so a retry is safe, put validation gates before training that fail the run loudly rather than warning, pass artefacts by immutable reference between stages, and set retry semantics per stage rather than globally.
Design the contract for a public API. How do you handle pagination, idempotency and versioning?
Model resources around client workflows, paginate with an opaque keyset cursor because offset pagination skips and duplicates rows under concurrent writes, make unsafe operations replayable with a client-supplied idempotency key, and evolve additively so that versioning stays a last resort rather than a routine.
One of your endpoints takes four minutes to complete. How should the API expose it?
Accept the request, return 202 with the location of an operation resource, and do the work behind a queue. Clients poll that resource or receive a signed callback, and either way the operation id is the contract - one that a callback can reach before the submitter has finished recording it.
Walk me through an order's journey from placement to delivery. How would you model its status?
Model the journey as milestone events, each carrying both the time it happened and the time you recorded it, and derive current status by projecting that set in a fixed milestone order rather than storing a mutable column, because events arrive late, twice and in the wrong sequence.
An event for 23:58 yesterday arrives at 00:20 today, after you have already published yesterday's totals. What should your pipeline do?
Decide it deliberately, because there is no correct default: you can hold the window open longer, accept the record and restate the figure, or drop it and report how much you dropped. What you must not do is let arrival order silently decide, which is what a pipeline keyed on ingestion time does.
A client times out and retries your POST /payments call. How do you make that endpoint idempotent?
Take an idempotency key from the client and store it in a uniquely-constrained row written in the same transaction as the effect, so the dedupe record and the work commit together. Replay the stored response on a repeat, refuse a retry arriving mid-flight, and expire keys past the retry horizon.
The MES is unreachable for four hours and the line keeps producing. What happens to the production record, and how do you reconcile afterwards?
The line survives on cached work orders and locally queued events, so the difficulty is the merge, not the outage. Reconciliation has to be idempotent, ordered by source timestamp rather than arrival, and honest about units that passed a gate nobody could evaluate. It also connects degraded mode to the point an interviewer is testing.
A subscriber's service is working on the network but no subscription exists in billing. How did that happen, and what do you do about it?
An activation half-succeeded and nobody owns the divergence. Detect it by reconciling the network's view against the subscription record, classify which side is wrong, re-drive fulfilment from stored intent rather than patching either side, and treat the unbilled period as a decided commercial policy.
A payment API times out and the client retries. How do you guarantee the customer is not charged twice?
Prevent a double charge on payment retry with an idempotency key tied to the purchase intent, a unique constraint, atomic charge recording, honest in-flight retry responses and settlement reconciliation.
What is the difference between a queue and a log, and what does a broker mean when it claims exactly-once?
A queue distributes work and forgets each message once acknowledged; a log is a retained, partitioned, replayable record that many consumers read independently at their own offsets. Use this message queues answer to show the decision, trade-off, and evidence rather than a memorised definition. It also connects event log to the point an interviewer is testing.
Design ticketing for a 60,000-seat stadium where every seat goes on sale at 10am. How do you sell each seat exactly once?
Selling a specific seat is a uniqueness problem, not a throughput one, so the seat row is the serialisation point and the design lives or dies on the reservation hold: a short expiring claim written atomically, plus a queue in front so the contention never reaches the database at full force.
A user submits the form twice and you get two identical orders. Why did the check-then-insert not prevent it, and how do you fix it in the database?
Two transactions can each run the SELECT before either commits, so neither sees the other and both inserts succeed. The fix is a serialisation point the database owns - a unique index on a natural or client-supplied key - plus a defined answer for whoever loses the race. It also connects idempotency to the point an interviewer is testing.
A driver spends part of the day with no mobile signal. How do you design the app so the round still works?
Treat the device as a first-class writer rather than a cache: it generates its own identifiers, records two timestamps per event, and queues durably until the network returns. Every submission carries an idempotency key because retries are certain, and genuine contradictions go to a human.
A customer's bank shows the money left their account and you have no order. How does your checkout make that impossible, and how do you find the ones that already happened?
Write the order before you call the payment provider and key both with the same idempotency token, so a timeout leaves a record you can resolve. Then reconcile the provider's ledger against your orders daily in both directions, because a lost outcome is silent by default. Use this payment orchestration answer to show the decision, trade-off, and evidence rather than a memorised definition.
Three days of your visibility events are unrecoverable and freight is still moving. How do you re-establish where everything is?
Rebuild rather than reconstruct: most of those events still exist in carrier systems, EDI mailboxes and handheld queues, so re-ingest them idempotently by date range, then close the residual gap with physical observation at yards and terminals. It only works if raw inbound feeds were archived apart from the projections built from them.
Walk me through what happens between a customer order being captured and the service being live on the network.
The order is decomposed against the product catalogue into technical tasks on separate systems, each with its own latency and failure mode. Because nothing spans them transactionally, correctness comes from idempotent tasks, compensating actions, a fallout queue and jeopardy monitoring.
Checkout calls pricing, tax, fraud, inventory and a session store. Which of those are you willing to carry on without, and what does the shopper see?
Sort each dependency by what the loss looks like. Price and payment authorisation must fail closed because the loss is unrecoverable; personalisation degrades silently. Tax and fraud sit between, and the answer is a written policy with a bounded exposure, not a timeout value.