The Scalability Cube (X, Y, Z Axis Scaling)
When your system hits a scaling wall, there are exactly three directions you can scale. The AKF Scale Cube gives you a mental model for every scaling decision you'll ever make — every technique maps to one of three axes.
The AKF Scale Cube
Developed by AKF Partners (who helped scale eBay), the Scale Cube describes three orthogonal dimensions of scaling. You can apply one, two, or all three simultaneously.
X-Axis: Horizontal Duplication
Clone Everything
The simplest scaling approach: run multiple identical copies of your entire application behind a load balancer. Each copy can handle any request.
- How: Deploy N identical instances, put a load balancer in front
- Scales: Throughput (N copies = ~N× capacity)
- Cost: Linear — each copy needs full resources (CPU, memory)
- Limitation: Doesn't help if one request is too large for a single server (e.g., a query that scans 10TB)
Example: 3 identical web servers behind an Nginx load balancer, each running the same code, connecting to the same database.
Y-Axis: Functional Decomposition
Split by Service/Function
Break your monolith into separate services, each responsible for one business capability. This is the microservices approach.
- How: Separate Auth Service, Product Service, Order Service, Search Service
- Scales: Complexity and team autonomy — each service scales independently
- Cost: Operational overhead (service mesh, distributed tracing, API contracts)
- Limitation: Doesn't help if one service still has too much data
Example: Extracting search into its own service with Elasticsearch, so the product catalog team and search team can deploy independently.
Z-Axis: Data Partitioning (Sharding)
Split by Data
Each server runs the same code but is responsible for only a subset of the data. Requests are routed based on some attribute (customer ID, geography, etc.).
- How: Shard by user ID (users A-M → Shard 1, N-Z → Shard 2)
- Scales: Data volume and write throughput
- Cost: Complex routing, cross-shard queries are expensive, rebalancing is hard
- Limitation: Doesn't help if one shard still gets all the hot traffic (celebrity problem)
Example: Slack shards by workspace — each workspace's messages live on one database shard.
Combining the Axes
You Can (And Should) Use All Three
The axes are orthogonal — applying one doesn't prevent applying others:
- X + Y: Microservices, each with multiple replicas behind their own LB
- X + Z: Multiple copies of a sharded database (read replicas per shard)
- Y + Z: Separate services, each sharding their own data
- X + Y + Z: Microservices, each replicated, each sharding their data
Most large-scale systems eventually apply all three. The question is which to apply first.
Decision Framework: Which Axis First?
Match the Axis to Your Bottleneck
| Bottleneck | Axis | Action |
|---|---|---|
| CPU/memory saturated across all features | X-Axis | Add more identical servers |
| Code is too complex, teams stepping on each other | Y-Axis | Extract services by business domain |
| Database too large, writes too slow | Z-Axis | Shard by tenant/customer/region |
| One feature consumes disproportionate resources | Y-Axis | Extract that feature into its own service |
| Hot partition / one customer dominates | Z-Axis | Re-partition with better key or isolate tenant |
🏢 Real-World: How eBay Evolved Using All Three Axes
eBay's scaling journey is the textbook example of the Scale Cube in action:
- 2000 — X-Axis: Cloned the monolithic Perl application behind load balancers. Fast, but the codebase became unmanageable.
- 2002 — Y-Axis: Decomposed the monolith into ~220 distinct services (search, bidding, listing, payment). Each team owned their service.
- 2004 — Z-Axis: Sharded databases by item category and seller ID. Buyer data and seller data partitioned differently based on access patterns.
- All three together: Each service (Y) runs multiple instances (X) and shards its data (Z). The result: eBay handles billions of API calls per day.
Lesson: They didn't apply all three at once. They started with the simplest (X), and only moved to Y and Z when X alone wasn't enough.
Interactive: Scale Cube Advisor
Select a bottleneck scenario and choose which axis to apply. See if your choice matches the optimal strategy: