When a queue redelivers an identical order message, how do you design the case that proves it is applied once?
answer
- The transport may hand it back
- One effect, not one error
- Same identity on both deliveries
- Wait for the second delivery's consumption
- Prove the case can go red
basics
~20 sPublish the identical order message twice — same identity, same body — wait for evidence that the second delivery was consumed, then assert a single visible effect: one row appended, one balance movement, one outbound notification.
solid answer
~50 sTreat the duplicate as data, not as an accident. **Capture** the effects you will assert on as counts before anything is published. **Act** by handing the consumer the same message twice, with the same identity field and the same body — a second message with a fresh identity is a different message the consumer may legitimately apply. **Wait** on evidence that the second copy was consumed: a processed counter advancing, the consumer's committed position moving past it, an audit record for that identity appearing twice. Sleeping instead makes the case pass whenever the second delivery is merely slow. **Assert** one visible effect as a delta from the baseline — one appended row, one balance movement, one outbound notification. Finally, run the case against a build with the duplicate guard removed and confirm it goes red, or you have a green result that proves nothing.
code
pseudocode · 14 linesmsg = { messageId: "m-9f21", type: "OrderPlaced", orderId: "o-4471", amount: 250 }
before = readEffects(orderId = "o-4471") # counts and totals, not flags
publish(queue = "orders", message = msg)
awaitCondition(() => consumedCount(messageId = "m-9f21") == 1)
publish(queue = "orders", message = msg) # identical body, identical identity
awaitCondition(() => consumedCount(messageId = "m-9f21") == 2) # the SECOND one was consumed
after = readEffects(orderId = "o-4471")
assert after.orderRows == before.orderRows + 1
assert after.ledgerEntries == before.ledgerEntries + 1
assert after.notificationsSent == before.notificationsSent + 1go deeper
Be ready to say why the same message can be delivered more than once and what the case must end up asserting: one effect, not the absence of an error. Knowing the difference between one delivery and one application is the point.
Explain the mechanics end to end: the same identity on both deliveries, a wait on evidence the second was consumed, and effects asserted as deltas from a captured baseline rather than as absolute totals.
Show the production judgment: prove the case can fail, choose deliberately between publishing twice and driving a real redelivery, and assert on every downstream a duplicate would double rather than only the primary write.
Own the argument about where this property is proved — once per consumer as a contract case, or re-proved inside every end-to-end flow — and what each choice costs in suite time, diagnosis speed and the confidence it actually buys.
## Why the same message arrives twice A transport that promises to deliver each message *at least* once will sooner or later hand the same message to a consumer more than one time. The publisher's acknowledgement was lost so it published again; a consumer instance restarted between doing the work and recording that it had done it; an operator replayed a range of the stored backlog after an incident. None of that is a fault to be repaired at the transport — it is the contract you accepted. The property that has to hold lives in the consumer: **applying the same message twice must leave the product in the state one application would have left it in.** That property is invisible to ordinary happy-path cases, because ordinary cases deliver each message exactly once. It needs a case of its own. ## The skeleton of the case 1. **Capture a baseline.** Read every effect you intend to assert on *before* publishing anything, as counts and totals rather than as expected absolute values. A case that expects `ledgerEntries == 1` is hostage to whatever else ran against that deployed target; a case that expects `ledgerEntries == before + 1` is not. 2. **Deliver the message once and let it settle.** You are proving the *second* delivery adds nothing, so the first has to be fully applied first. Wait on evidence, not on a clock. 3. **Deliver the identical message again.** Identical means the same identity field and the same body — the same `messageId`, the same `orderId`, the same amount. A second message carrying a fresh identity is a *different* message, and a consumer is entitled to apply it. 4. **Wait for the second delivery to be consumed.** This is the step most replay cases skip, and skipping it is exactly what makes them lie. 5. **Assert one visible effect** on something a second application would move: one row appended, one balance movement, one outbound notification. 6. **Prove the case can fail.** Run it against a build with the consumer's duplicate guard removed and watch it go red. A replay case that has never failed is indistinguishable from one that cannot fail. ## The false pass, and how to close it The trap is timing. You publish the duplicate, you immediately count rows, you see one row, the case is green — and it would have been just as green if the consumer had died, if the second copy had been misrouted, or if it were still sitting in the queue waiting to be picked up. **You proved the second copy had not been applied yet, which is a completely different statement from "it was applied and changed nothing".** Under load in a pipeline run, where consumption lags, this case passes for the wrong reason far more often than it passes for the right one. Closing the hole means finding a signal that the second delivery actually reached the code under test: - a **processed counter** the consumer already publishes, read before and after and expected to advance by one; - the consumer's **committed position** in the queue moving past the second copy; - an **audit or log record keyed by the message identity**, expected to appear twice even though the effect appears once; - an **echo the handler emits on every delivery** — an outbound event or a touched timestamp that happens whether or not the work was repeated. If nothing in the system can tell you a message was consumed, name that as a gap. A consumer that cannot say how many times it handled something is also a consumer nobody can operate during an incident. ## Where the duplicate comes from | Injection route | What it exercises | Caveat | | --- | --- | --- | | Publish the identical body and identity twice from the case | The consumer's guard, end to end | Needs a publish path that accepts a caller-supplied identity | | Withhold the acknowledgement so the transport hands the message back | The real redelivery path, with its real timing | Slower, and needs a seam to suppress the acknowledgement | | Replay a stored message from an earlier position in the backlog | The operational replay people actually run after an incident | Replays neighbouring messages too unless the range is narrow | Publishing twice is the default because it is fast and deterministic. The other two routes are worth one case each on a system where operators really do replay ranges by hand. ## Keeping the case honest as the system grows - Assert **deltas**, never absolute totals, so the case survives a shared deployed target. - Keep the replay case **separate** from the happy-path case, so a red result names which property broke rather than pointing at the flow in general. - Mint **fresh business identifiers per run** (`orderId`, `paymentId`) so two runs at once cannot collide on the same record and blame each other. - Assert on **every downstream a duplicate would double**, not just the primary write. Consumers routinely guard the database write and forget the outbound notification, so the record is right and the customer gets two messages.
- Your case pauses for two seconds after the second publish instead of waiting on a signal. What can it still report honestly?Only that one effect existed two seconds later. It cannot distinguish a guard that worked from a second delivery that had not been consumed yet, so it passes for the wrong reason whenever consumption lags — which is exactly when a pipeline run is busiest. Replace the pause with a wait on a consumption signal the system already exposes.
- How would you prove the assertion would actually fail if the consumer applied the message twice?Run it once against a build with the duplicate guard removed, or apply the same effect a second time by hand, and watch the case go red. Until you have seen it fail, a green result is untested. Repeat that negative control whenever the handler's effects change, so the assertion cannot drift onto something a second application would not move.
- Why publish the byte-identical message rather than a second message carrying a new identity?A new identity makes it a genuinely different message, and a correct consumer is supposed to apply it. The case would then assert one effect after two legitimate instructions, which is a different property and usually a wrong one. Duplicate handling is defined over identity, so the replay must repeat the identity exactly.
Counting rows straight after publishing the duplicate is like glancing at the till before the second customer has reached it and concluding nobody was served twice.
saying these in an interview costs you the question
- Assumes duplicates cannot happen because the transport promises delivery
- Pauses for a fixed period instead of waiting for the second delivery to be consumed
- Sends a second message with a fresh identity and calls it a replay
- Asserts only that the second delivery raised no error
- Never checks the case fails when the duplicate guard is removed
- Asserts an absolute total rather than a delta from a captured baseline