A Tale of a Scale Cube: Harmonizing your System Growth
I found Scale Cube from “The Art of Scalability” [Abbott & Fisher, 2015]. Scale cube is similar to the rule of thumbs on how your decision to scale out your system to handle a certain amount of access, based on the prediction of future growth.
X-Axis
X-Axis scaling is a common way to scale a monolith application. You can run multiple instances of the application behind a load balancer to distribute requests among the N instances of the application. This approach is suitable to solve the availability of your system.
This approach is also known as Horizontal Scaling.
Z-Axis
Z-Axis scaling is a common way to scale a monolith application by partitioning based on certain measurement. The measurement can be by a user identifier or user geolocation. Not only applicable for User, but also possible to apply it for Order records, Catalogue of products, or Content.
By doing this, in case one or two instances crashes, it will affect only a segment of users.
Y-Axis
Y-Axis scaling is a common way to scale a monolith application by decomposing its functions into separated application. For example separating user management, order management, and product management into an independent application.
Currently, this approach equals to Microservices approach or Vertical Scaling.
Combining Altogether
Let's start with a fictional company, ScaleStore an online store. At the first beginning, they start the company with a monolith system which handles user management, catalogue management, and order management in a monolith application.
Gradually, their customer increase day by day. Then they started to get complains due to service unavailability during peak hours. So, they start to duplicate the monolith app into several instances.
Instead of decomposing the monolith app into Microservices (Y-Axis split), they choose to implement X-Axis split. This is a wise approach for a startup company, because:
- They can keeps engineer resources to built new features and bug fixing, instead of rewrite existing system into independent applications.
- The duplicating instance is the easiest way to improve system availability. So, the customers can continue shopping without waiting for any long new development.
The story does not end only by duplicating a lot of instances. Now, they have a new problem, a hundred thousands daily access. The multiple monolith applications can’t handle the huge access, due to the locking in each of instances (example: Request related to catalogue causing block for requests to see order history, due to limited hardware resource in an instance). So they decide to build microservices by decomposing functions of the current application.
But, they also realized that the competition in the online shop very high, they can’t stand for a month or two with the current condition. Meanwhile splitting into Microservices, they also start to implement the Z-Axis split. Because the Z-Axis can give the system a new relaxation while waiting for new Microservices ready for production.
They applying rules to segmenting user by user modulo. If the result of the user id modulo is at range 0–2, they will go to X-Axis split in Bucket 1, so on and so on until user modulo at range 6–9 in Bucket 3. Bucket N is a term to a set of instances that served an N segment of users. So, if there was a problem in Bucket 1, it will only affect User mod 0–2, the rest of the user segments (3–9) can do their activities.
After 3 months plus 11 months, the delay because of the monolith codebase similar to spaghetti (we will discuss this latter on how to avoid bad codebase, even for monolith app). The microservices ready to go to production. Because they already implement X&Z Axis before. Now, they can implement fully XYZ Axis.
As you can see, there are several new applications: User management, Order management, and Catalogue management. Each of the applications has its own duplicate and bucket for segmentation. By implementing this, now they reach all sides of scalability. The user still can browse the catalogue, when the order management has a problem. Even the catalogue system at Bucket 1 has a problem, the user for Bucket 2–3 still can browse the catalogue. Again, even a box in Bucket 2 for catalogue system crash, the user in Bucket 2 still can browse product catalogue using the other boxes. Now, your system is reaching infinity and goes beyond so far from the starting point.
To infinity…and beyond — Buzz Lightyear
Another Consideration
So, maybe there was a budget limit in our scenario for ScaleStore. After building the microservices, they face a serious blow on engineer salary (due to delay and etc). And after a serious discount war with competitors, ScaleStore can’t implement Z-Axis. Because by isolating each of stack of microservices into many buckets will causing the CFO head exploding. So, they only will go to X&Y Axis scale strategy.
This approach should be sufficient for ScaleStore. At least their system now can work without locking because of many cross-functional activities (catalogue, order, log in, etc) happened in a single instance. And they also have a duplicate set of instances for each functionality.
What About Database Scalability?
We will discuss how to handle database scalability in the next article.
Conclusion
Before deciding whether you want to split your application, please do it gradually, from X-Axis, Z-Axis, then Y-Axis. You need to test the market first, don’t spill your money for technology only. Built a discipline that technology is supporting business. So, while your business grows, your technology should follow to grow.
Always pay attention to non-technical barriers, such as time constraint, market competition, business momentum, and cost to support system development. Because without it, you will only build a luxury scalable system above the graveyard of your business.