Production engineering
Reveal answer and reasoning
A recovery protocol should bind a stable scoped request key to canonical meaningful input and commit its receipt with the local effect. After an uncertain response, the caller reuses that identity or reads its durable outcome rather than inventing another command. Decide explicitly whether a later version invalidates receipt replay, as this fixture does. Outbox dispatch and consumer effects then require their own duplicate-delivery and crash-recovery rules; local atomic persistence cannot guarantee external exactly-once execution.
Request equivalence is explicit and narrower than an unrestricted semantic comparison: quantity and the serialized original typed condition are bound together. Reusing a key with changed meaning conflicts. Later unrelated writes can also make an otherwise matching saved receipt noncurrent, producing409 under this chosen protocol. A new stale condition produces412 instead. SQLite's immediate write ownership makes this local decision boundary inspectable, but no general cross-database transaction guarantee follows.
The outbox row records intent only; publication, consumer replay handling, ordering and effects outside this database need separate owners. A successful receipt does not demonstrate that any broker or remote consumer ran.
A strong report links the uncertain first response to persisted version, receipt and event counts, then records replay and incompatible-request outcomes independently. The portable program establishes only its one-owner decision sequence; the external fixture supplies the real typed-header and local transaction evidence. A senior explanation identifies the exact request fingerprint, current-receipt policy and missing external-effect boundary. It also recognizes that the document response, command receipt and publication intent are different artifacts.
This makes the capstone a concrete recovery exercise with honest limits, rather than a claim that combining three familiar patterns automatically yields production authentication or universal exactly-once processing.
What a strong answer covers
- A recovery protocol should bind a stable scoped request key to canonical meaningful input and commit its receipt with the local effect.
- Request equivalence is explicit and narrower than an unrestricted semantic comparison: quantity and the serialized original typed condition are bound together.
- A strong report links the uncertain first response to persisted version, receipt and event counts, then records replay and incompatible-request outcomes independently.
Common pitfall
Request equivalence is explicit and narrower than an unrestricted semantic comparison: quantity and the serialized original typed condition are bound together. Reusing a key with changed meaning conflicts. Later unrelated writes can also make an otherwise matching saved receipt noncurrent, producing409 under this chosen protocol. A new stale condition produces412 instead. SQLite's immediate write ownership makes this local decision boundary inspectable, but no general cross-database transaction guarantee follows. The outbox row records intent only; publication, consumer replay handling, ordering and effects outside this database need separate owners. A successful receipt does not demonstrate that any broker or remote consumer ran.
Follow-up questions
- Why does replacing the original If-Match value with the result ETag change the saved request identity during a replay?
- Why does an outbox row prove persisted intent rather than broker publication or a consumer effect?
Self-review
Choose what to revisit. These marks are your own assessment and are separate from lesson completion.