Command Palette

Search for a command to run...

Hectal
Phase 10Advanced11 of 18 in Database Design

Distributed Data: Consistency, Transactions and Change Streams

Consistency models from linearizable to eventual, CAP and PACELC in practice, quorums, two-phase commit and sagas, the outbox pattern and CDC with Debezium, and idempotency keys and deduplication.

As soon as data lives in more than one place (replicas, shards, services, caches, search indexes), you must decide what each reader is allowed to see and how changes propagate. This phase gives you the vocabulary and the patterns.

Kafka-specific details are covered in depth in the Kafka course; here the focus is the database side.

0/5 · 0%
5 topics ~43 min 9 code blocks & diagrams
Start with the first topic
1
10.1

Consistency Models

Consistency models define which values a read may return. Linearizability (strong consistency) makes the system behave like a single copy in real time; sequential and causal consistency relax real-time ordering; session guarantees (read-your-writes, monotonic reads) fix the most visible anomalies for a single user; eventual consistency only promises convergence. Conflict resolution decides what happens when replicas accept concurrent writes.

8 min 1 code practice

2
10.2

CAP, PACELC and Quorums

CAP says that during a network partition a system must choose between consistency (refuse some requests) and availability (answer with possibly stale data). PACELC adds that even without partitions there's a trade between latency and consistency. Quorum systems tune this with N replicas, W write acks and R read replicas: R + W > N gives overlapping reads and writes.

8 min 1 diagram 1 code practice

3
10.3

Distributed Transactions: Two-Phase Commit and Sagas

Two-phase commit makes several resources commit atomically: a coordinator asks all participants to prepare, then to commit. It blocks if the coordinator fails after prepare. Sagas split a business transaction into local transactions with compensating actions, orchestrated by a coordinator or choreographed by events. They trade isolation for availability.

9 min 1 diagram 1 code practice

4
10.4

Dual Writes, the Outbox Pattern and CDC

Writing to the database and publishing to Kafka (or updating a cache or search index) in two separate steps loses or duplicates events when either step fails. The outbox pattern writes the event into an outbox table in the same transaction as the business change; a relay or CDC (Debezium reading the WAL) publishes it. Consumers must handle duplicates and ordering per key.

9 min 1 diagram 2 code practice

5
10.5

Idempotency: Keys, Deduplication and Retry-Safe Writes

Networks time out, clients retry and consumers redeliver, so every write that matters must be safe to apply twice. Idempotency keys stored with a unique constraint make a repeated request return the original result; deduplication tables make consumers ignore redelivered messages; natural unique constraints and conditional updates make many operations idempotent by design.

9 min 1 code practice