Linearizability
  └── Sequential Consistency
        └── Causal Consistency
              └── Read-Your-Writes
                    └── Monotonic Reads
                          └── Eventual Consistency  (weakest)

Write(x=1) → completes at time T
Any Read(x) after T, from any node → must return 1

If Read(x) returns 1, then all subsequent reads from all nodes must also return 1.

Process A: Write(x=1), then Write(x=2)
Process B: sees x=1 before x=2 (order preserved per process)

But: Process C may see x=2 before x=1 if it reads from a different replica.

User posts comment (Write A)
User reads their comment (Read B — causally depends on A)
User replies to comment (Write C — causally depends on B)

Causal consistency guarantees: any node that shows Write C must also show Write A.
Concurrent writes by unrelated users may arrive in different order at different replicas.

User writes profile update → Write goes to primary
User immediately reads their profile → Read goes to replica

❌ WITHOUT read-your-writes: replica hasn't caught up → user sees old profile → "why didn't my update save?"
✅ WITH read-your-writes: session routed to primary for reads, or replica waits until caught up

User reads x=5 from replica A
User's next request hits replica B (which lags behind replica A)

❌ WITHOUT monotonic reads: user sees x=3 — time appears to go backward
✅ WITH monotonic reads: replica B either catches up or the read is routed to a replica that has seen x=5

Write(x=5) to primary
Replica A: returns x=5 immediately (already replicated)
Replica B: returns x=3 (replication lag: 400ms behind)
Replica C: returns x=0 (just started replication)

All three will return x=5 eventually — but "eventually" may mean seconds or minutes.

CP systems (choose consistency under partition):
  PostgreSQL primary + synchronous standby
  CockroachDB (SERIALIZABLE + Raft)
  ZooKeeper, etcd, Consul

AP systems (choose availability under partition):
  Cassandra (tunable consistency — default is AP)
  DynamoDB (eventual consistency by default)
  CouchDB
  DNS

If Partition (P): choose between Availability (A) and Consistency (C)
Else (E — normal operation): choose between Latency (L) and Consistency (C)

// ❌ Classic read-your-writes bug in a Node.js API
// Primary is in us-east-1. Read replica is in us-west-2 (400ms replication lag).

async function updateUserProfile(userId: string, name: string) {
  await db.primary.query(
    'UPDATE users SET name = $1 WHERE id = $2', [name, userId]
  );

  // Immediately read back — goes to replica (load balancer routes reads)
  const user = await db.replica.query(
    'SELECT name FROM users WHERE id = $1', [userId]
  );

  return user; // ← Returns OLD name. User sees "your change didn't save."
}

// ✅ Option 1: Route the post-write read to the primary
async function updateUserProfile(userId: string, name: string) {
  await db.primary.query('UPDATE users SET name = $1 WHERE id = $2', [name, userId]);
  const user = await db.primary.query('SELECT name FROM users WHERE id = $1', [userId]);
  return user; // Always consistent — reads from the source of truth
}

// ✅ Option 2: Return the data you wrote — no read needed
async function updateUserProfile(userId: string, name: string) {
  await db.primary.query('UPDATE users SET name = $1 WHERE id = $2', [name, userId]);
  return { id: userId, name }; // You already know what you wrote
}

// ❌ User's requests routed to different replicas by a round-robin load balancer
// Replica A is ahead of Replica B by 2 seconds of replication lag

// Request 1 → Replica A: messages.count = 15
// Request 2 → Replica B: messages.count = 12  ← went backward!
// User sees message count decrease. Appears as a UI bug.

// ✅ Sticky sessions: pin each user to one replica for the duration of a session
// All of user's reads go to the same replica — monotonic reads guaranteed
// (unless that replica restarts, in which case you re-pin)

Counter CRDT: increment-only counter that merges correctly across replicas
  Node A: count=5, Node B: count=3 (both incremented from count=2)
  Merge: max(5,3) = 5 ✅  (OR: each node tracks its own increments → sum on read)

Set CRDT (G-Set): grow-only set
  Node A: {a, b, c}, Node B: {b, d}
  Merge: {a, b, c, d} ✅

LWW-Register (Last-Write-Wins): uses timestamp to resolve conflicts
  Node A: x=5 at T=100, Node B: x=3 at T=120
  Merge: x=3 (T=120 wins) — silently discards Node A's write

Phase 1 — Prepare:
  Coordinator → all participants: "Can you commit?"
  Participants → Coordinator: "Yes, prepared" (locks resources)

Phase 2 — Commit:
  Coordinator → all participants: "Commit"
  Participants commit and release locks

Coordinator CRASHES after receiving all "prepared" responses.
All participants: resources locked. Cannot commit. Cannot abort.
Cannot make progress without coordinator recovery.
← This is the blocked-participant problem.

Order placement Saga:
  Step 1: Reserve inventory     → (on fail) → Release inventory reservation
  Step 2: Charge payment        → (on fail) → Refund payment
  Step 3: Create shipment       → (on fail) → Cancel shipment
  Step 4: Send confirmation     → (on fail) → Send cancellation email

Each step is a local transaction — ACID within its own database.
No distributed lock held across steps. No coordinator that can block.
Failure at step 3 triggers: cancel shipment + refund + release inventory.

// Choreography-based Saga (event-driven)
// Each service listens for events and publishes its own

// inventory-service
eventBus.on('order.created', async (event) => {
  const reserved = await inventory.reserve(event.orderId, event.items);
  if (reserved) {
    eventBus.emit('inventory.reserved', { orderId: event.orderId });
  } else {
    eventBus.emit('inventory.failed', { orderId: event.orderId });
  }
});

// payment-service listens to 'inventory.reserved', charges, emits 'payment.completed'
// If payment fails, emits 'payment.failed' → inventory-service compensates