How do replication and sharding work for database scaling?

Database scaling becomes critically important when a single physical server can no longer handle increased read and write loads. Replication and sharding represent two main architectural approaches to solving this problem. They allow distributing the load across multiple machines and ensuring high system availability.

Replication involves copying data from a primary server, usually called the master, to one or more subordinate servers known as replicas. The master handles all write operations, such as adding, updating, and deleting data, and then synchronizes these changes with the replicas. Replicas, in turn, serve read requests, which unloads the primary database and increases the overall throughput of the application.

There are several types of replication, among which asynchronous and synchronous are the most popular. With asynchronous replication, the master confirms the write to the user immediately without waiting for a response from the replicas, which ensures high performance but carries the risk of losing recent changes in the event of a sudden master failure. Synchronous replication guarantees data consistency across all nodes, but increases response time due to network latencies.

Sharding, unlike replication, divides the database itself into parts called shards and distributes them across different servers. Each shard contains only a subset of the total data of the entire system. This method is used for horizontal scaling of writes when the volume of data or the intensity of write operations exceeds the capacity of a single hard drive and processor.

Choosing a sharding key is a crucial stage in designing such an architecture. A poor choice of key can lead to a situation where one shard is overloaded with requests while others are idle, nullifying all the advantages of a distributed system. Therefore, architects need to carefully analyze data usage patterns before implementing sharding.