Scale Cube
A model describing three independent axes of scaling — cloning, functional decomposition, and data partitioning — each addressing a different limit.
X-axis: cloning. Run more identical instances behind a load balancer. Simplest, and it works only for stateless work; it does nothing for a shared database that is itself the bottleneck.
Y-axis: functional decomposition. Split by capability — separate services for orders, payments, catalogue. Allows independent scaling of components with different profiles and different teams, at the cost of distributed-systems complexity.
Z-axis: data partitioning. Split by data — shard by customer, region or tenant, each partition handling a subset. The axis that addresses data volume and write throughput, which the other two cannot.
The value of the model is diagnostic: it names which axis a given bottleneck requires. Adding instances (X) when the constraint is write throughput on a single database achieves nothing, and this is an extremely common mistake.
Vertical scaling — a bigger machine — remains the correct first answer more often than architectural fashion admits. It requires no code change, no distribution, and modern instances are very large. Its limits are a hard ceiling, a step-function cost curve, and downtime to resize. Use it until it stops working, then scale out — provided the design does not preclude scaling out later.