┌─────────┐
│  Master │  ← Single point of failure
│ (Writes)│  ← Bottleneck for metadata
└────┬────┘
     │
  ┌──┴──┬──────┐
  ▼     ▼      ▼
┌───┐ ┌───┐ ┌───┐
│S1 │ │S2 │ │S3 │  Slaves (read replicas)
└───┘ └───┘ └───┘

Problem: If master fails, writes stop!

      ┌───┐
   ┌─▶│ A │◀─┐
   │  └───┘  │
   │         │
┌──┴──┐   ┌──┴──┐
│  D  │   │  B  │  ← All nodes are equal
└──┬──┘   └──┬──┘  ← Any node can serve reads/writes
   │         │     ← No single point of failure
   │  ┌───┐  │
   └─▶│ C │◀─┘
      └───┘

Every node can accept writes and reads!

-- Strong consistency (wait for majority)
SELECT * FROM messages WHERE user_id = 123
  USING CONSISTENCY QUORUM;

-- Fast reads (return immediately, may be slightly stale)
SELECT * FROM messages WHERE user_id = 123
  USING CONSISTENCY ONE;

-- Critical writes (wait for all replicas)
INSERT INTO payments (user_id, amount) VALUES (123, 99.99)
  USING CONSISTENCY ALL;

User writes message to Node A

Normal case:
Node A → Replicate to B, C (success)

Network partition (B and C unreachable):
Node A → Store "hint" locally
         ↓
      Later, when B and C come back:
         ↓
Node A → Replay hints to B and C

                  Token Range: 0
                        │
                    ┌───▼───┐
                    │ Node A│
                    │ Token │
                    │ Range │
                    │ 0-25  │
                    └───┬───┘
                        │
     Token Range: 75    │         Token Range: 25
            │           │              │
        ┌───▼───┐       │          ┌───▼───┐
        │ Node D│       │          │ Node B│
        │ Token │       │          │ Token │
        │ Range │       │          │ Range │
        │ 76-99 │       │          │ 26-50 │
        └───┬───┘       │          └───┬───┘
            │           │              │
            │           │              │
            │       ┌───▼───┐          │
            │       │ Node C│          │
            └───────│ Token │──────────┘
                    │ Range │
                    │ 51-75 │
                    └───────┘
                        │
                  Token Range: 50

Before (4 nodes):
A [0-25] → B [26-50] → C [51-75] → D [76-99]

Add Node E at token 63:
A [0-25] → B [26-50] → C [51-62] → E [63-75] → D [76-99]
                                    ↑
                        Only C and E exchange data!
                        Other nodes unaffected

┌──────────────────────────────────────────────────────┐
│ 1. Client sends write to any node (Coordinator)     │
└──────────────────────┬───────────────────────────────┘
                       │
                       ▼
┌──────────────────────────────────────────────────────┐
│ 2. Coordinator determines replicas (using ring)      │
│    Example: RF=3 → Nodes B, C, D                     │
└──────────────────────┬───────────────────────────────┘
                       │
        ┌──────────────┼──────────────┐
        ▼              ▼              ▼
   ┌────────┐     ┌────────┐     ┌────────┐
   │ Node B │     │ Node C │     │ Node D │
   └────┬───┘     └────┬───┘     └────┬───┘
        │              │              │
        │ 3. Each replica does:       │
        │    a) Append to CommitLog (disk, sequential)
        │    b) Write to MemTable (memory)
        │    c) Return ACK
        │              │              │
        └──────────────┼──────────────┘
                       │
                       ▼
┌──────────────────────────────────────────────────────┐
│ 4. Coordinator waits for consistency level           │
│    - ONE: Wait for 1 ACK (fastest)                   │
│    - QUORUM: Wait for 2/3 ACKs (balanced)            │
│    - ALL: Wait for 3/3 ACKs (slowest, most consistent)│
└──────────────────────┬───────────────────────────────┘
                       │
                       ▼
┌──────────────────────────────────────────────────────┐
│ 5. Return success to client                          │
└──────────────────────────────────────────────────────┘

Later (asynchronously):
   MemTable full → Flush to SSTable (sorted, immutable file on disk)

┌──────────────────────────────────────────────────────┐
│ 1. Client sends read to coordinator                  │
│    SELECT * FROM messages WHERE user_id = 123        │
└──────────────────────┬───────────────────────────────┘
                       │
                       ▼
┌──────────────────────────────────────────────────────┐
│ 2. Coordinator determines replicas (Nodes B, C, D)   │
│    Consistency = QUORUM → Query 2 replicas           │
└──────────────────────┬───────────────────────────────┘
                       │
                ┌──────┴──────┐
                ▼             ▼
           ┌────────┐    ┌────────┐
           │ Node B │    │ Node C │
           └────┬───┘    └────┬───┘
                │             │
     3. Each node checks:     │
        a) MemTable (memory)  │
        b) Bloom Filters (is data in SSTable?)
        c) SSTables (disk, may be multiple)
                │             │
                └──────┬──────┘
                       │
                       ▼
┌──────────────────────────────────────────────────────┐
│ 4. Coordinator compares timestamps                   │
│    - If data matches → Return to client              │
│    - If mismatch → Trigger read repair               │
└──────────────────────┬───────────────────────────────┘
                       │
                       ▼
┌──────────────────────────────────────────────────────┐
│ 5. Return most recent data to client                 │
└──────────────────────────────────────────────────────┘

-- Fixed schema
CREATE TABLE users (
    id INT PRIMARY KEY,
    name VARCHAR(50),
    email VARCHAR(100)
);

-- Must pre-define all columns

-- Flexible schema
CREATE TABLE users (
    id UUID PRIMARY KEY,
    name TEXT,
    email TEXT
    -- Can add more columns per row dynamically
);

-- Different rows can have different columns
INSERT INTO users (id, name, email) VALUES (...);
INSERT INTO users (id, name, email, phone) VALUES (...);

CREATE TABLE messages (
    user_id UUID,
    timestamp TIMESTAMP,
    message_id UUID,
    body TEXT,
    PRIMARY KEY (user_id, timestamp)
    --           ^^^^^^^^  ^^^^^^^^^
    --           Partition  Clustering
    --           Key        Column
) WITH CLUSTERING ORDER BY (timestamp DESC);

CREATE KEYSPACE my_app WITH REPLICATION = {
    'class': 'SimpleStrategy',
    'replication_factor': 3
};

CREATE KEYSPACE my_app WITH REPLICATION = {
    'class': 'NetworkTopologyStrategy',
    'dc1': 3,  -- 3 replicas in datacenter 1
    'dc2': 2   -- 2 replicas in datacenter 2
};

Replication Factor = 3 (Nodes A, B, C)

┌────────────┬────────────┬───────────────┬──────────────┐
│ Level      │ Writes     │ Reads         │ Trade-off    │
├────────────┼────────────┼───────────────┼──────────────┤
│ ONE        │ 1 ACK      │ 1 response    │ Fastest,     │
│            │            │               │ least        │
│            │            │               │ consistent   │
├────────────┼────────────┼───────────────┼──────────────┤
│ QUORUM     │ 2/3 ACKs   │ 2/3 responses │ Balanced     │
│            │            │               │ (most common)│
├────────────┼────────────┼───────────────┼──────────────┤
│ ALL        │ 3/3 ACKs   │ 3/3 responses │ Slowest,     │
│            │            │               │ most         │
│            │            │               │ consistent   │
└────────────┴────────────┴───────────────┴──────────────┘

R + W > RF  (Read + Write replicas > Replication Factor)

Examples:
- R=QUORUM (2), W=QUORUM (2), RF=3 → 2+2 > 3 ✓ (Strong)
- R=ONE (1), W=ALL (3), RF=3     → 1+3 > 3 ✓ (Strong)
- R=ONE (1), W=ONE (1), RF=3     → 1+1 > 3 ✗ (Eventual)

-- Product catalog (read-heavy, eventual OK)
SELECT * FROM products WHERE id = 123
  USING CONSISTENCY ONE;

-- Shopping cart (needs consistency)
SELECT * FROM carts WHERE user_id = 456
  USING CONSISTENCY QUORUM;

-- Payment processing (critical!)
INSERT INTO orders (id, total, status) VALUES (...)
  USING CONSISTENCY ALL;

# cassandra.yaml
phi_convict_threshold: 8  # Lower = more sensitive to failures
                          # Higher = more tolerant of network delays

-- Writes succeed even if some replicas unreachable
WRITE USING CONSISTENCY ONE;
READ USING CONSISTENCY ONE;

-- System always available, but may be temporarily inconsistent

-- Writes fail if quorum unreachable
WRITE USING CONSISTENCY QUORUM;
READ USING CONSISTENCY QUORUM;

-- Sacrifice availability for consistency (may fail during partition)

Client → Coordinator (Node A)
         ↓
Node A checks: "B is down, C and D are alive"
         ↓
Node A writes to C and D (replicas)
         ↓
Node A stores "hint" for B locally:
   "When B comes back, replay this write"
         ↓
Later: B comes online
         ↓
Node A replays hints to B

Client reads at QUORUM (2/3 replicas)

Node A: {user: "alice", age: 30, updated: T1}
Node B: {user: "alice", age: 30, updated: T1}
Node C: {user: "alice", age: 25, updated: T0}  ← Stale!

Coordinator detects mismatch:
   → Return newest (age: 30) to client
   → Background: Send newest to Node C (read repair)
   → Eventually: All replicas consistent

# Compare data across replicas using hash trees
nodetool repair

# Cassandra:
# 1. Builds Merkle trees for each replica
# 2. Compares hashes (efficient, no full data transfer)
# 3. Identifies differences
# 4. Streams missing/different data

Without compaction:
MemTable flushes → SSTable1 (10 MB)
MemTable flushes → SSTable2 (10 MB)
MemTable flushes → SSTable3 (10 MB)
...
MemTable flushes → SSTable100 (10 MB)

Problem: Read must check 100+ SSTables (SLOW!)

Background process merges SSTables:
SSTable1 + SSTable2 + SSTable3 → SSTable_merged (30 MB)

Benefits:
- Fewer files to check (faster reads)
- Remove deleted data (tombstones)
- Reclaim disk space

CREATE TABLE sensor_data (
    sensor_id UUID,
    timestamp TIMESTAMP,
    temperature DECIMAL,
    humidity DECIMAL,
    PRIMARY KEY (sensor_id, timestamp)
) WITH CLUSTERING ORDER BY (timestamp DESC)
  AND COMPACTION = {'class': 'TimeWindowCompactionStrategy'};

-- Efficient queries:
-- "Get last 24 hours of data for sensor X"
SELECT * FROM sensor_data
WHERE sensor_id = ?
  AND timestamp > now() - 24h;

CREATE TABLE user_timeline (
    user_id UUID,
    post_timestamp TIMESTAMP,
    post_id UUID,
    author_id UUID,
    content TEXT,
    PRIMARY KEY (user_id, post_timestamp, post_id)
) WITH CLUSTERING ORDER BY (post_timestamp DESC);

-- Efficient queries:
-- "Get Alice's feed (last 50 posts)"
SELECT * FROM user_timeline
WHERE user_id = 'alice'
LIMIT 50;

CREATE TABLE page_views (
    page_id TEXT PRIMARY KEY,
    views COUNTER
);

-- Increment counter (no read-before-write!)
UPDATE page_views
SET views = views + 1
WHERE page_id = '/home';