Event sourcing, CQRS and the transactional outbox

The dual-write hazard

In microservice architectures, an application frequently needs to update its local database and publish an event to a message broker:

// ANTI-PATTERN: Non-atomic dual write
async function placeOrder(order: Order) {
  await db.orders.insert(order); // Step 1: Database Commit
  await kafka.publish('orders.v1', order); // Step 2: Message Publish
}

Why dual-writes inevitably fail:

• If Step 1 succeeds and the network fails or app crashes before Step 2, the order exists in DB but downstream inventory, shipping, and notification services never receive the event (Ghost Order).
• If Step 2 executes first and DB commit fails on constraint violation, external services charge credit cards for an order that does not exist.

---

The Transactional Outbox Pattern

The Transactional Outbox Pattern solves the dual-write hazard by leveraging the database's local ACID transaction guarantee:

1. Atomic Insertion: In a single ACID transaction, write both the business entity (orders table) and an outbox record (outbox table):

   BEGIN TRANSACTION;
   INSERT INTO orders (id, user_id, total, status) VALUES ('ord_99', 'usr_1', 149.00, 'CREATED');
   INSERT INTO outbox (id, aggregate_type, payload, created_at)
   VALUES ('evt_99', 'Order', '{"id":"ord_99","total":149.00}', NOW());
   COMMIT;

2. Message relay: A separate process publishes the outbox rows to the broker. It can poll the outbox table, or use change data capture: Debezium, for example, reads the database's change log (MySQL's binlog, PostgreSQL's logical replication stream) and sends the changes to Kafka.
3. Delivery: An event is published only if its transaction committed, and is not lost if the service crashes afterward, all without a two-phase commit. But the relay may publish a message more than once, so consumers must be idempotent (lesson 7.2).

---

Event sourcing

Event sourcing goes further: instead of storing only the current state, capture every change to the application's state as a sequence of events, and treat that sequence as the source of truth. You can then discard the current state and rebuild it by replaying the events, or work out what the state was at any point in the past. The events also make a natural stream for other services to consume.

---

CQRS: command query responsibility segregation

CQRS uses a different model to update information than the model you use to read it:

• Command side (writes): A model built to enforce the business rules, often a normalized, transactional schema.
• Query side (reads): One or more read models shaped for the queries, often denormalized and possibly in different stores (a search index, a cache), kept up to date asynchronously from the write side's events, so reads may briefly lag writes.

Martin Fowler, who popularized the pattern's description, warns that for most systems CQRS adds risky complexity: use it only on specific parts of a system where the read and write needs really differ.