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.
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.
Writes land on leaders, reads fan out to replicas, and lag appears when durability and latency pull in opposite directions.
higher throughput, possible stale reads
182 qps requested
failover and quorum effects
lower with stronger coordination
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.
Overview
When one database server is no longer enough, there are three directions to grow: copy the data to more servers, split it across servers, or make the one server bigger. This simulator has a tab for each. In the replication tab you choose a single-leader, multi-leader or leaderless topology, switch between synchronous and asynchronous replication, add replicas, change the load and the share of writes, and watch replication lag, latency, stale-read risk and availability respond. You can also take the primary down and see how each topology copes. In the sharding tab you choose hash or range partitioning and a shard key such as user_id, region, created_at or tenant_id, then watch how rows spread and whether a sample query reaches one shard or all of them. Range partitioning on a timestamp, for example, sends all new writes to the same shard. In the scaling tab you combine a bigger server, replicas, shards and connection pooling against a given load. The point is that replicas scale reads and availability, while write capacity grows only with a bigger primary or with more shards, and sharding adds the most complexity.
Try this
- In the replication tab, switch from async to sync replication and compare replication lag, latency and stale-read risk, then take the primary down in a single-leader setup.
- In the sharding tab, choose range partitioning on created_at and watch new writes pile onto one shard, then switch to hash on user_id.
- In the scaling tab, raise the write share of the load and see that adding replicas stops helping while adding shards still does.
Frequently asked questions
- What is the difference between replication and sharding?
- Replication keeps full copies of the same data on several servers, which helps reads and availability. Sharding splits the data so each server holds only part of it, which is what lets writes scale.
- Synchronous or asynchronous replication: which should I use?
- Synchronous replication waits for a replica to confirm each write, so a failover loses nothing but every write is slower. Asynchronous replication is faster but can lose the most recent writes if the primary fails.
- How do I choose a shard key?
- Pick a key that spreads writes evenly and that most queries include, so they hit one shard. Keys that grow over time, such as a timestamp with range partitioning, create a hot shard.
Try next
// simulator
SQL Terminal Simulator
Practice SQL in an interactive browser terminal. Learn SELECT, WHERE, ORDER BY, DISTINCT, aggregates, GROUP BY, HAVING, JOINs, subqueries, and window functions against a small e-commerce schema, with single-table queries evaluated live and verified Postgres output.
// simulator
PostgreSQL Terminal Simulator
Practice the psql tool and Postgres engine in an interactive browser terminal. Explore with meta-commands, read real EXPLAIN plans, add an index to turn a sequential scan into a bitmap index scan, and use BEGIN and ROLLBACK to make changes safe, all against a small e-commerce database with verified PostgreSQL output.
// simulator
MongoDB Terminal Simulator
Practice MongoDB queries in an interactive browser terminal. Learn find and projections, query operators like $lt, $gt, and $in, sort, skip, limit, countDocuments, insert, update, delete, and the aggregation pipeline with $match, $group, and $sort, against a small e-commerce dataset that runs live in your browser.