Outbox, CDC & Event Sourcing

"Save to the DB and publish to RabbitMQ" is two systems with no shared transaction. Whatever order you pick, the crash between them corrupts one side — Module 01's invalidation race was one instance; here's the general disease:

Both orderings lose: DB-then-publish + crash = state changed, world never told (downstream caches, notifications, analytics silently diverge — undetectably). Publish-then-DB + crash = world told about state that doesn't exist (consumers act on a grant that was never made). Wrapping both in @Transactional is a lie — the rabbitTemplate call isn't in the DB transaction.

Make the event a row: write the business change and the event into the same database, same ACID transaction. A separate relay reads the outbox table and publishes. The dual write becomes single-write + asynchronous delivery of something durably recorded:

@Transactional
public void grant(String userId, String planId) {
  entitlementRepo.save(new Entitlement(userId, planId, ACTIVE));
  outboxRepo.save(OutboxEvent.of(               // SAME transaction — atomic with the state change
      "EntitlementGranted", userId,             // aggregateId → partition key downstream (M15 §04)
      json(userId, planId), UUID.randomUUID())); // eventId → consumer idempotency key (M16)
}   // commit: either both rows exist or neither — the race is gone by construction

Design decisions that matter:

• Relay style — polling vs CDC: polling publisher (SELECT ... FOR UPDATE SKIP LOCKED batch → publish → delete/mark) is simple, adds poll-interval latency and DB read load; CDC (§03) tails the transaction log — lower latency, no poll queries, one more moving system. Start polling; graduate to CDC when volume or latency demands.
• The relay is at-least-once by construction (publish succeeded, mark crashed → republish): outbox guarantees delivery, not uniqueness — consumer idempotency (M16) remains mandatory. Outbox and idempotent consumers are two halves of one pattern.
• Ordering: relay must publish per-aggregate in commit order (order by id within aggregateId, one publisher per partition of the outbox, aggregateId as the broker partition key). Parallel relays without partition discipline reorder — M15 §04's sins, self-inflicted.
• Hygiene: the outbox is a queue in a database — monitor its depth and oldest-unpublished age as first-class SLIs (a growing outbox is an invisible event outage); aggressive cleanup of published rows (the table wants to be near-empty); events carry schema versions (M15 §05).

Event sourcing inverts storage: the event log is the truth; current state is a fold over events (state = replay(events)), cached as snapshots. Distinct from "using events" (outbox publishes events about state) — here there is no state table to diverge from.

• What it buys: perfect audit (the history is the data — billing disputes answered by replay); temporal queries ("entitlements as of March 3" for a rights audit); retroactive fixes (correct the fold, replay); new projections from history (build the recommendations feature against three years of watch events you already have).
• What it costs, honestly: every read needs a projection (CQRS becomes mandatory, not optional — commands fold events, queries hit eventually-consistent read models, and M04's read-your-writes anomalies apply inside your own service); schema evolution forever (events are immutable — you'll maintain upcasters for every version you ever emitted); deletion/GDPR is genuinely hard (crypto-shredding per-user keys is the workable answer); replay time engineering (snapshots, parallel rebuilds); and a mental-model tax on every engineer who touches it.
• The honest selection rule: event-source aggregates whose history is a business asset with regulatory or product value — billing/payments ledger (naturally event-shaped: ledgers ARE event sourcing, centuries old), entitlement grants/revocations (rights audits), maybe playback QoE (analytics replay). CRUD the rest: profiles, preferences, catalog metadata gain nothing from replay and pay full cost. "Event source everything" is how platforms drown; per-aggregate selection is the staff answer.

Fast trackStep 1 (~35 min): the kill-test on your own outbox is the proof that matters.

Self-check