Search for a command to run...
Your application is running on multiple servers. Traffic is growing. Everything looks good — until one day, your database becomes the slowest part of the system.
No comments yet. Be the first to comment.
Most system design discussions jump straight into complex architecture patterns—monoliths, microservices, event-driven systems, and distributed databases. But in real engineering, systems don’t begin
When building traditional software, engineers write tests to make sure code works correctly. Every time you change a feature or update a package, automated tests run to catch bugs before they reach re
When you first start building applications, you usually think about buying or renting a server—a computer that sits somewhere in a data center, running 24/7, waiting for someone to use their app. But
You've built your application. Now, it's time to deploy it to Amazon Web Services (AWS). So, you open the AWS Console, click through a dozen complex menus, create an Amazon S3 bucket, wire up an AWS L
When you launch a new application, a single-server architecture is usually more than enough. Your users send requests, the server processes the backend logic, talks to the database, and returns a resp
Horizontal scaling solves many problems. But it doesn't solve all of them.
One of the most common misconceptions among developers is that adding more application servers automatically means the application can handle more users. Unfortunately, that's not how it works.
In this article, you'll learn why databases eventually become the bottleneck as your system grows, how replication improves read-heavy workloads, and when sharding becomes the only way forward.
Imagine you're running a library.
At first, there's one librarian. A handful of visitors arrive each hour — they ask for books, return borrowed ones, or register for new memberships. Everything runs smoothly.
Now imagine the library becomes wildly popular. Instead of ten visitors per hour, hundreds arrive every minute.
You hire more receptionists to greet them. That's essentially what adding more application servers does.
But here's the problem: every receptionist still has to walk to the same librarian every time someone needs a book.
Eventually, the receptionist isn't the bottleneck anymore. The librarian is.
Databases work exactly the same way.
No matter how many application servers you add, they all talk to the same database. Every request that needs to fetch user data, place an order, update a profile, or process a payment ends up reaching that one database.
At some point, the database simply can't keep up — not because databases are slow, but because every machine has limits.
Every database operation consumes resources.
Reading data requires CPU time, memory, and disk access. Writing data demands even more — the database must validate constraints, update indexes, write to storage, and confirm the data is safely persisted.
As traffic grows, so does the work. And adding more application servers can actually make things worse, because you've increased the number of clients hammering the same database simultaneously.
There are two common strategies to address this:
Replication — when reading data is the bottleneck
Sharding — when a single database can no longer handle the overall workload
They look similar on the surface, but they solve very different problems.
Suppose your application receives thousands of requests per minute. If you look closely, most of them are simply reads — users browsing products, viewing profiles, searching posts, or checking order history. Very few requests actually modify data.
So why should one database handle every single read?
The answer is: it doesn't have to.
Database replication means creating multiple copies of the same database. One database is designated the primary — it receives all write operations. The additional databases, called replicas or read replicas, continuously copy data from the primary and handle read requests.
Going back to the library analogy: instead of one librarian answering every question, you now have several librarians, each with an identical copy of every book. Visitors can be served simultaneously without anyone waiting in a long queue.
Replication sounds perfect — but it introduces an important trade-off.
Replicas are not updated instantly. There's usually a small delay between when the primary receives a write and when the replicas reflect that change. Most of the time this delay is just a few milliseconds, which is perfectly acceptable for most applications.
But consider this: you update your profile picture and immediately refresh the page. If that request is routed to a replica that hasn't synced yet, you might briefly see your old photo. This delay is called replication lag.
Understanding this trade-off matters more than knowing the technology itself. The right question isn't "Can I use replication?" It's "Can my application tolerate slightly stale data?"
If the answer is yes, replication is a great solution.
Replication improves read performance. But every write still goes to the same primary database.
For applications with heavy write workloads — think banking systems, messaging platforms, ride-sharing apps, or payment gateways — write traffic alone can overwhelm that primary node. Adding more read replicas does nothing to help here.
When the bottleneck shifts to writes, you need a fundamentally different strategy.
Instead of copying the database, you split it.
Imagine the library has grown into the largest in the country. Hiring more librarians isn't enough anymore — there's simply too much information in one place.
So you build multiple libraries. One stores books from A–H. Another covers I–P. The third holds Q–Z. Visitors don't browse every library — they go directly to the one that has what they need.
Database sharding works the same way. Instead of storing all your data in a single database, you divide it into smaller pieces called shards. Each shard holds only a portion of the data.
For example:
Users A–H → Shard 1
Users I–P → Shard 2
Users Q–Z → Shard 3
Now writes are spread across multiple databases. No single node bears the full load.
These two techniques are often mentioned together, but they address different layers of the scaling problem:
| Replication | Sharding | |
|---|---|---|
| What it does | Creates copies of the same data | Splits data across multiple databases |
| Best for | Read-heavy workloads | Write-heavy or high-volume workloads |
| Also provides | Redundancy and failover | Higher storage and write capacity |
| Trade-off | Replication lag (stale reads) | Routing complexity and harder queries |
In large-scale systems, the two are often used together — each shard can have its own set of read replicas, giving you both write scalability and read distribution at the same time.
The most important lesson in system design isn't which technology to use — it's understanding which problem you're actually solving.
Replication improves reads but accepts that data may be slightly out of date. Sharding improves write capacity but adds complexity to your architecture. Neither is universally better. They're answers to different questions.
The goal isn't to build the most sophisticated system possible. It's to identify the bottleneck clearly, and apply the simplest solution that removes it.
