The scale cube

The scale cube, from Martin Abbott and Michael Fisher's The Art of Scalability, names three independent ways to split a system. Each axis solves a different problem. Naming the axis tells you what a change will buy and what it will cost.

The big idea

Picture a cube with three directions. Moving along one axis does not require moving along the others. You can clone a service without splitting it, or shard data without splitting the code.

The limit of each axis matters. Cloning does not help write-heavy workloads, because every copy still has to apply every write. Splitting by function does not help if one database still holds everything.

Walking through it

Take a marketplace whose order database is maxed out.

1. X first. Stateless API servers are cloned to handle more requests. The database is not helped, because every clone still sends its writes to the same primary.
2. Y next. Checkout is split out, so its load and deploys are separate from search. The order database is still shared.
3. Z last. The order database is sharded by merchant ID. Each shard holds a part of the orders, and the writes spread across shards.

In a design review, the sentence becomes: "We have exhausted X for the orders database. The next step is Z, by merchant ID."

Most large systems use all three axes. A common pattern splits by function into a few services, clones each service, and shards the largest data stores.

Common mistakes

• Cloning to fix a write bottleneck. Writes still go to one primary.
• Splitting services before splitting data. Services that share one database are still coupled.
• Sharding by an arbitrary key. Pick a key that matches the access pattern, such as merchant ID for orders.

Check yourself

1. Which axis helps a write-heavy database that is already at its limit?

   Answer: Z, data partitioning. Cloning (X) gives every copy all the data, so writes do not spread.

2. Where do read replicas fit on the cube?

   Answer: on the X axis. They are clones of the same data.

Key takeaways

• The scale cube names three independent ways to split a system: clone, split by function, split by data.
• Each axis solves a different bottleneck and has a different limit.
• Cloning does not reduce writes, so write-heavy systems need data partitioning.

Further learning

Next, see how to find the bottleneck that these splits are meant to fix, in finding the bottleneck.