Read Write Configuration

NoSQL Replication: Read & Write Configuration

The Library Story 📚

Imagine you run a magical library with multiple branches across town. You have ONE main library (the Primary) where all new books arrive first. Then you have several branch libraries (the Replicas) that get copies of those books.

But here’s the tricky part:

• Who can check out books? (Read)
• Who can add new books? (Write)
• How do we make sure everyone has the same books? (Consistency)

This is exactly what Read Write Configuration solves in NoSQL databases!

🔖 Read Replicas

What Are They?

Read Replicas are copies of your database that can only answer questions—they can’t make changes.

Think of them as photocopy machines at each branch library. They have copies of all the books, so people can read them. But if someone wants to donate a new book? They must go to the main library.

Why Use Them?

┌─────────────────┐
│  MAIN DATABASE  │ ← All writes go here
│    (Primary)    │
└────────┬────────┘
         │ copies data to...
    ┌────┴────┬────────┐
    ▼         ▼        ▼
┌───────┐ ┌───────┐ ┌───────┐
│Replica│ │Replica│ │Replica│
│   1   │ │   2   │ │   3   │
└───────┘ └───────┘ └───────┘
    ▲         ▲        ▲
    └────┬────┴────────┘
         │
    Many users can
    READ from here!

Simple Example:

• Your app has 10,000 users reading data
• Only 100 users writing data
• Without replicas: Main database handles everything = SLOW!
• With 3 replicas: Reads spread across 4 servers = FAST!

🎯 Read Preferences

What Is It?

Read Preference tells the database: “Where should I look for my answer?”

It’s like asking: “Which library branch should I visit to find my book?”

The Five Choices

Quick Example

// Always read from primary (freshest data)
db.users.find().readPref("primary")

// Read from nearest server (fastest)
db.users.find().readPref("nearest")

When to Use What?

• Showing bank balance? → primary (must be accurate!)
• Showing product reviews? → secondary (slightly old is OK)
• Global users? → nearest (speed matters most)

✍️ Write Concerns

What Is It?

Write Concern answers: “How many copies must confirm they saved my data before I can relax?”

Imagine mailing an important letter. Do you:

• Just drop it in a mailbox? (No confirmation)
• Wait for “delivered” notification? (Some confirmation)
• Wait for the person to call you back? (Full confirmation)

The Levels

┌─────────────────────────────────────────┐
│         WRITE CONCERN LEVELS            │
├─────────────────────────────────────────┤
│                                         │
│  w: 0  → "Fire and forget"              │
│         Don't wait for anything         │
│         ⚡ Fastest | 🎲 Risky           │
│                                         │
│  w: 1  → "Primary confirmed"            │
│         Main server saved it            │
│         ⚖️ Balanced                      │
│                                         │
│  w: 2  → "Primary + 1 replica"          │
│         Two copies exist                │
│         🛡️ Safer                         │
│                                         │
│  w: "majority" → "Most servers agree"   │
│         Can survive failures            │
│         🏰 Safest | 🐢 Slower            │
│                                         │
└─────────────────────────────────────────┘

Code Example

// Fast but risky (logging, analytics)
db.logs.insertOne(
  { event: "click" },
  { writeConcern: { w: 0 } }
)

// Safe (important user data)
db.users.insertOne(
  { name: "Alice", balance: 100 },
  { writeConcern: { w: "majority" } }
)

📖 Read Concerns

What Is It?

Read Concern answers: “How fresh must my data be?”

Back to our library: When you ask for a book list, do you want:

• Whatever the librarian remembers? (Fast but maybe outdated)
• The official catalog? (Accurate but slower)

The Levels

Simple Analogy

🏃 "local"        → Ask the nearest employee
📋 "majority"     → Check with most employees
📜 "linearizable" → Check the official record

Code Example

// Quick check (may be slightly stale)
db.products.find().readConcern("local")

// Reliable read (confirmed by most servers)
db.orders.find().readConcern("majority")

⚖️ Quorum

What Is It?

Quorum means “the minimum votes needed to make a decision.”

Think of it like a class vote:

• 5 students in class
• Need more than half to agree = at least 3 votes
• That’s your quorum!

The Magic Formula

┌─────────────────────────────────────┐
│                                     │
│   Quorum = (Total Servers / 2) + 1  │
│                                     │
│   3 servers → Quorum = 2            │
│   5 servers → Quorum = 3            │
│   7 servers → Quorum = 4            │
│                                     │
└─────────────────────────────────────┘

Why It Matters

Scenario: 5 servers, 2 go offline

Without Quorum:
  - Remaining 3 might disagree
  - Data becomes inconsistent 😱

With Quorum (needs 3):
  - 3 remaining can still agree ✅
  - System keeps working safely

Real Example

// Write must be confirmed by majority
db.payments.insertOne(
  { amount: 500 },
  { writeConcern: { w: "majority" } }
)
// With 5 servers: waits for 3 to confirm

⏱️ Replication Lag

What Is It?

Replication Lag is the time delay between:

1. Data written to the primary
2. Data appearing on replicas

It’s like when breaking news happens:

• News anchor reports it FIRST
• Then it spreads to social media
• Some people hear it 5 minutes later

That delay? That’s lag.

Why It Happens

┌─────────────────────────────────────────┐
│                                         │
│   PRIMARY                               │
│   ┌─────┐                               │
│   │ NEW │ ← Data written at 10:00:00    │
│   │DATA │                               │
│   └──┬──┘                               │
│      │                                  │
│      │ Network travel time...           │
│      │                                  │
│   ┌──┴──┐                               │
│   │COPY │ ← Arrives at 10:00:02         │
│   │     │                               │
│   └─────┘                               │
│   REPLICA                               │
│                                         │
│   LAG = 2 seconds                       │
│                                         │
└─────────────────────────────────────────┘

Common Causes

1. Network distance - Replica is far away
2. Heavy load - Primary is very busy
3. Large writes - Big data takes time to copy
4. Slow replica - Replica hardware is weak

The Problem It Creates

User writes: "Balance = $100"
         ↓
      PRIMARY has $100

User reads (from REPLICA):
         ↓
      Still shows $50! 😰
         (hasn't received update yet)

How to Handle It

// For critical reads: force primary
db.balance.find({ user: "alice" })
  .readPref("primary")

// Or wait for majority confirmation
db.balance.find({ user: "alice" })
  .readConcern("majority")

🎯 Putting It All Together

The Decision Flow

graph TD
    A["Need to READ data?"] --> B{How fresh?}
    B -->|Latest only| C["readPref: primary"]
    B -->|Recent enough| D["readPref: secondary"]
    B -->|Fastest| E["readPref: nearest"]

    F["Need to WRITE data?"] --> G{How safe?}
    G -->|Critical| H["w: majority"]
    G -->|Important| I["w: 2"]
    G -->|Fast OK| J["w: 1"]

Cheat Sheet Summary

🌟 Key Takeaways

1. Read Replicas = Extra copies for reading (reduces load)
2. Read Preferences = Where to read from
3. Write Concerns = How many must confirm a write
4. Read Concerns = How reliable must the read be
5. Quorum = Minimum votes for decisions
6. Replication Lag = Delay in copying data

Remember our library analogy:

• Main library = Primary database
• Branch libraries = Replicas
• Choosing which branch = Read Preference
• Confirming book was cataloged = Write Concern
• Checking official catalog = Read Concern
• Voting on decisions = Quorum
• Time for new books to reach branches = Replication Lag

You’ve got this! 🚀