TOPIC: Database Sharding and Replication

1. Meaning

• Sharding = split data across multiple DB servers → scale storage and write capacity.
• Replication = copy same data across multiple DB servers → improve read capacity, availability, and recovery.

Analogy: Sharding = divide books across multiple libraries. Replication = keep copies of same book in multiple libraries.

Project44 example: Bulk Tracking Search uses Elasticsearch terms queries. At large scale, tracking records can be distributed across shards; replicas can provide redundant copies and serve searches.

2. How it works

Sharding

Application

Shard router — hash(customerId) → shard

Shard 1

Customers A–F

Shard 2

Customers G–M

Shard 3

Customers N–Z

Each shard owns only part of dataset. Real systems usually route using partition keys or shard maps, not alphabetic ranges.

Replication

Primary DB

Accepts writes

Replicates changes

Replica 1

Read traffic

Replica 2

Failover copy

Primary commits write → replicas receive changes → reads may go to replicas. Async replication can mean stale reads.

3. Replication types

• Synchronous: Primary waits for required replica acknowledgements. Stronger durability/consistency guarantees, but higher latency and reduced write availability during network failures.
• Asynchronous: Primary responds before replicas catch up. Lower latency, but replica lag and possible loss of recent acknowledged writes during certain failures.
• Semi-synchronous/quorum: Wait for some acknowledgements, balancing latency and durability.

Choose async for read-heavy workloads tolerant of stale data; synchronous/quorum when stronger guarantees justify latency.

4. Sharding strategies

Choose hash-based sharding for broadly distributed keys. Choose range-based when range queries dominate and ranges can be balanced.

5. AWS mapping

Amazon RDS / Aurora

• Generic concept: Relational DB with primary and read replicas.
• AWS service: RDS read replicas, Aurora reader instances.
• AWS changes: Managed backups, failover options, monitoring; still pay for instances/storage and manage query design. Cross-region replication adds latency and complexity.
• Sharding: Usually application-managed or implemented through a compatible sharding layer; adding replicas does not automatically partition writes across independent DBs.
• Avoid when: Workload requires massive horizontal write scaling but relational features are not needed.

Amazon DynamoDB

• Generic concept: Partitioned key-value/document DB.
• AWS service: DynamoDB.
• AWS changes: AWS manages physical partitioning and scaling behavior. Design partition keys carefully to avoid hot partitions; pay by capacity/request model and storage.
• Avoid when: Relational joins, complex transactions across arbitrary entities, or flexible SQL queries dominate.

Amazon OpenSearch Service

• Generic concept: Distributed search engine with primary and replica shards.
• AWS service: Amazon OpenSearch Service.
• AWS changes: Managed deployment and monitoring, but shard sizing, mappings, query performance, and capacity planning still matter. Nodes and storage cost money.
• Project44 link: Bulk Tracking Search and alert matching use search-oriented data access. OpenSearch shards distribute indexed data; replicas add redundancy and can serve searches.

Key distinction: A DB shard owns different data. A replica holds a copy of data owned by another shard.

6. Capacity math

Assume:

• 10 million records.
• Average record = 1 KB.
• 3 shards.
• Replication factor = 2 total copies per shard (1 primary + 1 replica).

Steps:

• Logical data = 10M×1KB≈10GB10M * 1KB ≈ 10GB10M×1KB≈10GB.
• Per shard = 10GB/3≈3.3GB10GB / 3 ≈ 3.3GB10GB/3≈3.3GB.
• With 2 total copies = 10GB×2≈20GB10GB * 2 ≈ 20GB10GB×2≈20GB raw storage.
• Indexes, logs, metadata, and free-space headroom add more storage.

Replication increases storage, not logical data volume. Sharding alone does not create extra copies.

If incoming load = 3,000 writes/sec and distributed evenly across 3 shards → roughly 1,000 writes/sec per shard, before replication overhead and uneven key distribution.

7. Tradeoffs + interview Qs

Q1. Can replication solve write scaling?

Not automatically. Read replicas mainly scale reads. Writes still go through primary or shard owners.

Q2. Can sharding improve availability?

Potentially, but a failed shard can make its data unavailable unless replicas/failover exist.

Q3. What is a hot shard?

One shard gets disproportionate traffic. Fix skewed partition keys, distribute traffic, or isolate hot tenants/keys.

Q4. What is replica lag?

Replica has not applied latest writes. Monitor lag; route consistency-sensitive reads to primary or use stronger read guarantees.

Q5. How do cross-shard queries work?

Fan out query to relevant shards → merge results. Cost and latency rise with number of shards. Include shard key in query when possible.

Q6. How do you add a shard?

Update routing, migrate affected data, dual-read/write carefully if needed, validate consistency, then cut over. Avoid sudden uncoordinated remapping.

Q7. What is replication factor 3?

Three total copies per shard, typically one primary and two replicas. It does not mean three shards.

Q8. What happens during primary failure?

Promote eligible replica, redirect traffic, recover/reconcile writes if needed. Failover depends on replication mode and service configuration.

8. One-sentence interview answer

“Sharding splits different parts of data across DB nodes to scale storage and throughput; replication copies each shard across nodes to improve read capacity and resilience, at the cost of extra storage and consistency complexity.”

9. Memory trick

Sharding = split data. Replication = copy data.

Scale writes/storage → sharding. Scale reads/recovery → replication.