Loading...
Loading...
Browse 24 real-world technical and behavioral interview questions about Idempotency. Review scenarios, edge cases, and architectural best practices.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.