Production engineering
Reveal answer and reasoning
Design the invariant around the rows that must be atomically present, then assign delivery to a separately owned bounded dispatcher. Give the event a stable identity and payload contract so replay can be recognized downstream. Preserve actual pre-commit rollback and valid-commit checks through refactors, and add separate uncertain-response and duplicate-delivery scenarios when those features arrive. The companion's bundle explains correlation, the SQLite transaction proves local persistence and a later consumer test would prove another boundary.
Keeping these results separate prevents a useful outbox design from becoming an unsupported exactly-once claim about an entire distributed workflow.
For a production design, name which database owns the atomic business change and whether the publication intent can reside in that same transaction. Specify dispatcher claims, acknowledgment, retention and retry limits separately. A local sent flag cannot retract an already delivered message, so consumers need an appropriate duplicate-handling contract. Test rollback and duplicate identities through fresh storage reads rather than trusting an in-memory entity state.
Do not place an external payment inside the transaction and assume that local rollback reverses it; reconcile or redesign that separate effect explicitly.
What a strong answer covers
- The portable record groups quantity2 with event order:2; it does not execute SQL.
- Actual pre-commit failure leaves orders0/outbox0; valid commit leaves1/1.
- Persisted publication intent and external delivery have separate failure boundaries.
Common pitfall
Equating a committed outbox row with broker acceptance or exactly-once consumer execution.
Follow-up questions
- What state appears if business and event rows use separate commits?
- How does a lost acknowledgment after remote delivery affect replay?
Self-review
Choose what to revisit. These marks are your own assessment and are separate from lesson completion.