customers quickly, making scalability very important. The i rst go‐to solution is to scale horizontally
and duplicate the application over many servers and load balance the trafi c in a High Availability
(HA) manner, with a passive peer that becomes active if the active peer goes down. X‐axis scaling
improves the capacity and availability of the application. This option does not have development
cost implications but does result in higher hosting and maintenance expense. 3
You can scale an application along the Z‐axis. The application code is duplicated onto several
servers, similar to an X‐axis split, but in this case each server is responsible for only a frac-
tion of the data. A mechanism is put in place to route data to the appropriate server, perhaps
based on a user type or primary key. Z‐axis scaling benei ts from much the same performance
improvements as X‐axis scaling; however, it implies new development expense to rearchitect the
None of these solutions resolves the worsening application and development complexity. For this,
you need vertical scaling.
The application can be scaled along the Y‐axis. It is decomposed into functionality, service, or
resource. The way you do this is entirely your choice and will depend on the situation, although
division by use case is common. The idea is that each decomposed part should encapsulate a small
set of related activities.
To v isua lize the X‐, Y‐, and Z‐axis scaling, you draw an AKF scale cube, 4 as in Figure 15-4.
FIGURE 15-4: The AKF cube should have X‐, Y‐, and Z‐axis scaling.
Decomposing into Services
The microservice approach decomposes a monolithic application along the Y‐axis into services that
satisfy a single use case or a set of related functionality. These services are then duplicated on several
servers and placed behind a load balancer, X‐axis split. The data persistence may be scaled along the
Z‐axis by sharding the data based on a primary key.