ORIGINAL TECHNICAL PRACTICE
Make an operation safe to retry
A client times out after submitting a job, then retries. How would you prevent duplicate jobs without losing legitimate new requests?
Written for independent practice. The model answer presents one approach; clarify constraints and explain alternatives.
A REASONED APPROACH
Model answer.
Use a caller-supplied idempotency key scoped to the relevant operation and identity. Persist the key, request fingerprint and outcome atomically with job creation or through a carefully defined durable protocol.
Work through it
- Define key lifetime, uniqueness scope and response behavior for a retry. Reject reuse of the same key with a meaningfully different payload.
- Use a uniqueness constraint or conditional write so concurrent retries cannot create separate jobs. Represent in-progress, completed and failed states deliberately.
- After an uncertain response, look up the persisted outcome by key rather than assuming the operation failed. Test parallel retries, crashes and expiry boundaries.
Tradeoffs to discuss
- Retaining keys indefinitely consumes storage; expiring them limits how long retries remain protected. Downstream effects may need their own idempotency protocol.
Common pitfalls
- A cache-only key can disappear before the job state does. Generating a new key for every retry defeats the mechanism, while reusing one key for distinct jobs rejects legitimate work.