A requirement says the confirmation must follow the charge, yet the design promises no order between them. What do you assert?

## Separate the requirement from the mechanism "The confirmation must follow the charge" is a sentence about the business, not about a transport. It is usually shorthand for something narrower: *a customer must never be told their payment succeeded before it did*, or *the stored record must never show a confirmation with no charge behind it*. Those are properties of the settled outcome. They are true under every interleaving the design permits, and they can be asserted without any promise about arrival sequence. Start by asking the requester what a violation would look like to a person. If the answer is "the customer sees the wrong thing" or "the ledger is inconsistent", you have a state property. If the answer is genuinely "the second event must be processed after the first, and the design guarantees it", then you need a guarantee to test against — see the last section, because usually the design does not have one. ## Three substitutes, in order of preference | What you assert instead | What it needs | What it costs | |---|---|---| | The invariant every permitted sequence must satisfy | Nothing new; read the settled outcome | Reads the outcome once complete rather than watching it form | | A sequence value the events themselves carry | A producer-stamped counter or a causal reference field | A schema change if it is not there already | | Sequence, but scoped to where order is promised | A routing key the design orders by | Says nothing about anything outside that key | **The invariant.** Enumerate the sequences the design permits, and assert what is true in all of them: no confirmation without a matching charge; the balance after both events equals the same figure either way; a dependent record always references an existing cause. This is the strongest available assertion in most designs, and people undervalue it because it does not mention order — but a property that holds under every legal sequence is a *stronger* statement than one that holds under the sequence your run happened to get. **A carried sequence value.** If the events carry a counter stamped by their producer, or the later one references the earlier one by identifier, the sequence becomes a field you can read rather than a wall-clock accident. Then "the confirmation follows the charge" is an assertion about `confirmation.causeRef` pointing at a charge that exists, or about one counter being lower than another — deterministic, and independent of when anything arrived. **Scoped sequence.** Where the design really does order events under one routing value, assert sequence for events sharing that value and nothing else. Keep the scope visible in the case so the next reader does not widen it. ## What not to do - **Do not assert the sequence anyway and label the case intermittent.** That trades a design question for a maintenance cost and teaches the team that red sometimes means nothing. - **Do not assert your own production order.** The sequence in which the case emitted two events is not a property of the system; if the design does not carry it, no assertion can recover it. - **Do not tighten the deployment until the sequence holds** — one consumer instance, one producing path, no contention — and then claim the guarantee. You have asserted a property of a configuration nobody runs. - **Do not conclude that sequence is untestable.** It is testable exactly to the extent that something in the design carries it, and saying which part carries it is the answer the interviewer wants. ## When the honest answer is a design gap Sometimes the requirement really is a hard sequence guarantee, and the design offers nothing that carries it: no ordering key covering both events, no counter, no causal reference, two independent producing paths. No test can create that guarantee. Writing one anyway produces a case that is green when the system is lucky, which is worse than no case at all because it will be read as coverage. The right output is a finding, phrased in the design's own terms: *this requirement asks for a sequence the current design does not preserve; carrying a producer-stamped counter, or routing both events by the same key, would make it assertable.* Alongside it, ship the invariant case you can defend today, so the behaviour is not unguarded while the design question is decided. That is also the answer an interviewer is listening for. Anyone can write an assertion; the judgement being probed is whether you can tell a requirement that the system supports from one that it does not, and whether you say so before the assertion turns into an intermittent failure that somebody else inherits.