Skip to main content

Database Replication, Sharding & Scaling

Explore database replication, sharding, and scaling with an interactive simulator. Compare sync vs async replication, shard key choices, hot spots, failover behavior, read replicas, write scaling, connection pooling, cost, and latency.

Category: Database

What You Will Learn

  • Understand when replication helps reads and availability
  • See why sharding is needed for write scaling
  • Compare sync and async replication tradeoffs
  • Explore shard key selection and hot spot behavior
  • Balance database performance, reliability, and cost

Topics covered: database, replication, sharding, scaling, distributed-systems, postgresql, architecture, educational, interactive

// simulator

Database Replication, Sharding & Scaling

Explore database replication, sharding, and scaling with an interactive simulator. Compare sync vs async replication, shard key choices, hot spots, failover behavior, read replicas, write scaling, connection pooling, cost, and latency.

Supported byDigitalOceanDevDojoSMTPfastQuizAPIBecome a sponsor
Interactive architecture lab

See how databases survive load, failure, and growth

Replication improves availability and read throughput. Sharding distributes data and write pressure. Scaling combines both with bigger nodes, pools, and cost tradeoffs.

Replication
lag and failover
Sharding
hot spots and routing
Scaling
cost vs capacity
Primary
writes
Shard 1
replicated
Shard 2
hot tenant
Replica
reads
Replication topology

Writes land on leaders, reads fan out to replicas, and lag appears when durability and latency pull in opposite directions.

Primary
182 writes/sec
Replica 1
156 reads/sec
Replica 2
156 reads/sec
Replica 3
156 reads/sec
Write path
leader only
Read path
replica reads
Failure behavior
normal operation
Controls
Topology
Commit mode
Replicas
3
Load
650 qps
Writes
28%
Consistency preference
55%
Replication lag
331 ms

higher throughput, possible stale reads

Write capacity
280 qps

182 qps requested

Availability
99%

failover and quorum effects

Split-brain risk
4%

lower with stronger coordination

Operator readout

Lag is climbing. Move critical reads to the leader, lower write pressure, or increase consistency for safer reads.

Database replication, sharding, and scaling tradeoffs

Replication

  • Read scale: replicas can serve read traffic, but writes still need coordination.
  • Lag: async replication improves throughput but allows stale reads.
  • Failover: losing a primary requires promotion, consensus, or quorum behavior.

Sharding

  • Write scale: data is split across shards so multiple primaries can accept writes.
  • Shard keys: uneven keys create hot spots and scatter/gather queries.
  • Rebalancing: adding shards can move a lot of data if the partitioning strategy is poor.

Scaling

  • Vertical scaling: simpler, but eventually hits hardware and cost limits.
  • Read replicas: great for read-heavy workloads, weak for write-heavy workloads.
  • Combined designs: replicated shards are common for large production systems.

Try next

Sponsored
Carbon Ads
$ cd /games
// share