Skip to main content
Status: Proposed (RECONSTRUCTION — requires validation) · Date: 2026-08-17 (reconstructed) Refs: ../constitution/founding-constitution.md
⚠️ Reconstructed from the material we have, not recovered. Tags: [derived] is supported by evidence in the repository · [inferred] is deduced · [proposed] is a gap I filled.

Context

A command that changes state and then publishes an event has two failure modes that both corrupt the system: the publish fails and the event is lost, or the publish succeeds and the transaction rolls back and the event is a lie. Neither is acceptable when the event awards points or sends an email. [inferred]

Decision

Domain events are written to a transactional outbox inside the command’s transaction, and a relay publishes them afterwards. [derived] Direct publication from application code is forbidden. A single event stream feeds six consumers: realtime, outgoing webhooks, notifications, cache invalidation, metering, and search or analytics indexing. [inferred] — the drop names “six consumers” repeatedly and names the first five; the sixth is my reconstruction. Consumers are idempotent. At-least-once delivery is the contract, exactly-once is not offered, and every consumer is written to survive seeing a message twice. [derived]

Consequences

  • An event exists if and only if the state change it describes exists. That property is what makes the whole system reasonable about.
  • Adding a consumer is additive and touches no producer. − Events are eventually published, not instantly. Latency budgets account for it. − The outbox is a hot table and a partitioning candidate at volume.

What I could not determine

The sixth consumer. Five are named across the material; I have proposed search/analytics indexing as the sixth. [proposed]