7 Scaling out
This chapter covers
- Adding replication for high availability and high read throughput
- Master-Master replication and write conflict resolution
- Sharding your data for better data distribution and high write throughput
- Multi-tenancy
- Mixing Sharding and Replication
Software system engineers are in the never ending pursuit for building stable software systems. The biggest challenge of every data-driven system is the requirement to be able to grow larger, and to be as fault tolerant as possible, without one taking a bite off the other.
Imagine Amazon, for example, limiting the amount of products in their catalogue because their servers have limited storage space. Or allowing for huge product catalogues but accepting some down time every now and then because one of their servers crashed. This isn’t really acceptable, is it?
A fundamental player in this story is the database engine operating behind the scenes, and it usually breaks in one of two scenarios (or both combined!). The first case is when the data outgrows what a single database machine can hold. If your database server has 1TB of storage space available on disk, it obviously won’t be able to store 2TBs of data. While adding more disk space is sometimes possible, other factors like available RAM also plays a part in querying large data sets. For any database system there is some absolute upper limit to which you can scale the server hosting it, and this is where it breaks.