What is database sharding, and how does it differ from replication? When would you use each?

Replication vs Sharding

Replication (Copies of same data)

Primary → Secondary 1
        → Secondary 2
        → Secondary 3

All nodes have the SAME data

Purpose: High availability, read scaling, disaster recovery

Primary handles writes

Secondaries handle reads

If primary dies, secondary becomes primary (auto-failover)

Sharding (Data split across nodes)

Shard 1: Users A-M    → Primary + 2 Secondaries (replica set)
Shard 2: Users N-Z    → Primary + 2 Secondaries (replica set)

Purpose: Write scaling, storage scaling, horizontal scaling

When to Use Each

ProblemSolution

Read-heavy workloadReplication — Add secondaries for reads
Write-heavy workloadSharding — Distribute writes across shards
Need 99.99% uptimeReplication — Automatic failover
Dataset > single server diskSharding — Each shard holds a fraction
Complex queries across all dataReplication — All data on every node

MongoDB Sharding Architecture

Client → mongos (Router) → Config Servers (metadata)
                ↓
        Shard 1 (A-M)  ←→  Shard 2 (N-Z)  ←→  Shard 3 (logs)
        (replica set)       (replica set)       (replica set)

Shard Key Selection (CRITICAL)

// Enable sharding
sh.enableSharding("interviewOS");

// Choose shard key
sh.shardCollection("interviewOS.applications", { userId: 1 });

// Good shard keys:
// - High cardinality (many unique values)
// - Low frequency (even distribution)
// - Non-monotonic (not auto-increment, causes hot shards)

Bad Shard Key: Auto-increment

Shard 1: IDs 1-1000
Shard 2: IDs 1001-2000 (all NEW writes go here = hot shard!)

Good Shard Key: Hash

sh.shardCollection("interviewOS.questions", { _id: "hashed" });
// Even distribution, writes spread across all shards

Scaling Decision Tree

Is your dataset > single server capacity?
  → YES: Shard (horizontal scale)

Is your write throughput > single primary capacity?
  → YES: Shard (distribute writes)

Do you need more read throughput?
  → Add secondaries (replication)

Do you need high availability?
  → Replica set (minimum 3 nodes: 1 primary + 2 secondary)

Do you need BOTH?
  → Sharded cluster (each shard is a replica set)

Production Reality

Most apps start with replica set only (3 nodes). Sharding adds complexity:

Cross-shard queries are slower

Shard key migration is extremely difficult (choose wisely)

More infrastructure to manage

Add sharding only when you've exhausted vertical scaling and replication.