Typorithm · hard

Distributed Data (Saga/Outbox)

distributed-dataarchitecturesagaoutboxcqrs

Saved on this device

Full lesson · 8 learning steps Open any exercise for focused practice

Step 1 of 8 · intro card

Learn Distributed Data (Saga/Outbox)

Distributed Data & Ops

A database-per-service rules out easy distributed transactions: coordinate multi-service operations with sagas and compensating actions instead of two-phase commit, publish events reliably via a transactional outbox, answer cross-service queries with CQRS read models, and accept eventual consistency.

In microservices each service owns its data and no one else touches its store directly. That isolation is the point, but it means a single business operation often spans several services — and you can no longer wrap it in one database transaction.

A saga replaces the distributed transaction with a sequence of local transactions, one per service. If a later step fails, the saga runs compensating actions to undo the earlier ones, rather than locking everyone in a two-phase commit. To publish the events that drive the saga reliably, the transactional outbox writes each event into an outbox table inside the same local transaction as the data change, then a relay forwards it to the broker.

Cross-service reads use CQRS: a separate read model, kept up to date from those events, answers queries without joining across service boundaries. The price of all this is eventual consistency — downstream state converges shortly after a change instead of being instantly atomic.

Database-per-service rules out easy distributed transactions.

Sagas use compensating actions, not two-phase commit.

Transactional outbox publishes events atomically with the data change.

data_patterns:
  no_shared_db: per-service-data
  transaction: saga-not-2pc
  publish: transactional-outbox
  query: cqrs-read-models
  consistency: eventual

Read the implementation

Connect each part of the code to the concept before you type.

1. Database per service

Each service owns its own data store; no other service reads its tables directly, which rules out easy distributed transactions.

no_shared_db: per-service-data

2. Saga, not two-phase commit

A saga coordinates a multi-service operation as a sequence of local transactions, using compensating actions to undo on failure instead of a blocking two-phase commit.

transaction: saga-not-2pc

3. Transactional outbox

Events are written to an outbox table in the same local transaction as the data change, then relayed to the broker — so the event and the state change can never disagree.

publish: transactional-outbox

4. CQRS read models

CQRS keeps a separate, denormalized read model that answers cross-service queries without joining across service boundaries.

query: cqrs-read-models

5. Eventual consistency

Without a shared transaction across services you accept eventual consistency: read models and downstream services converge shortly after a change, not instantly.

consistency: eventual

A complete learning loop

Understand

Read the concept map and follow the code breakdown.

Reconstruct

Type the implementation, repair mistakes and work through every recall exercise.

Verify

Use the final check without hints; revisit weak concepts in short practice sessions.