Coding interviews
Reveal answer and reasoning
A durable design can store a unique scoped key, a canonical request fingerprint, an in-progress or completed state and the recorded response. It must define who executes an effect after a crash and which transaction can bind that effect to the record. When an external system cannot participate, an explicit reconciliation or outbox-style boundary is needed instead of an exactly-once slogan.
Expected lookup and insertion cost are O(1) dictionary operations plus key hashing. Retained entry count is bounded by capacity, but key lengths and payload representation still affect memory. There is no eviction policy; dropping old keys would change the period over which retries can be recognized. This local dictionary is not thread-safe and cannot provide distributed exactly-once effects. Accepting a record before or after an external payment leaves a failure window unless storage and effect ownership are designed together.
A key reused with changed payload must not silently replay an unrelated result.
The interview explanation should trace all five outcomes and identify the nonmutating branches. It should state that capacity limits new decisions and that a key is bound to payload meaning. A senior answer then distinguishes entry bounds, thread safety, durable state and external-effect semantics, which require different mechanisms. The console dictionary demonstrates none of the latter distributed guarantees. This task is valuable precisely because a correct tiny state machine can expose those boundaries clearly, giving reviewers a concrete counterexample to designs that remember only seen keys or reject every retry once a cache is full.
What a strong answer covers
- A durable design can store a unique scoped key, a canonical request fingerprint, an in-progress or completed state and the recorded response.
- Expected lookup and insertion cost are O(1) dictionary operations plus key hashing.
- This local dictionary is not thread-safe and cannot provide distributed exactly-once effects.
Common pitfall
This local dictionary is not thread-safe and cannot provide distributed exactly-once effects. Accepting a record before or after an external payment leaves a failure window unless storage and effect ownership are designed together. A key reused with changed payload must not silently replay an unrelated result.
Follow-up questions
- Replay x after the ledger is full and verify replay rather than full. Hint: capacity limits new ownership, not lookup of already owned decisions. Add invalid empty-key and negative-amount cases.
- What does idempotency-key expiry mean for a retry arriving after the retention horizon?
Self-review
Choose what to revisit. These marks are your own assessment and are separate from lesson completion.