Let’s briefly review the AKF Scale Cube (read more here), a model describing three methods for scaling technology platforms.

The three axes of the cube are;

  1. X - horizontal duplication
  2. Y - segmentation by service or function
  3. Z - segmentation by customer or geography

X axis in the persistence tier

Of the three axes by which you can scale your systems, the X axis (horizontal replication) is often the first used at the web and application layers.  Load balancing workloads across a pool of identical web and app servers is a standard approach to scale and also improves availability by eliminating SPOFs at the web and app layer.  The scale and availability benefits of horizontally duplicating VMs and containers far outweigh the cost.  The cost vs. benefit analysis gets more complex as we look at the persistence tier – DBs and storage.  DBs are typically one of the most expensive portions of the technology stack, especially if licensed RDBMS are used.  Storage costs have been dropping but can still be considerable.  Does X axis scaling make sense at the persistence tier?  In many cases, yes, particularly if there is a defined time period the X axis split is expected to serve.

As compared to Y and Z axis scaling, X axis features some advantages;

  • Relatively easy to do
  • Fast to implement
  • Scales transactional systems well

X axis scaling also has a disadvantage compared to the other axes – cost.  Duplicating systems and storage gets expensive quickly.  This reinforces the notion of apply X axis in the persistence tier for a defined period before shifting to Y and/or Z axis scaling.

What situations lend themselves well to X axis scaling in the persistence tier?

  • High read to write ratios – employ a write master and multiple read slaves
  • Reporting and BI – run reporting and BI workloads against a replica DB
  • Search – deploy a caching layer backed by a replica DB

Consider a situation where a monolithic codebase was written to get the minimum viable product out the door – a sound choice in the early day of a startup.  Success driven growth is now straining the system.  Multiple web and app servers are in use, but they all call a single database.  Reporting is also run against the same DB.  There is increasing interest in productizing reporting, something sure to increase DB workload.  Company leadership realizes they need to architect for scale quickly and have chosen a services-oriented architecture.  Engineering will refactor the monolith into independent services, communicating asynchronously – a Y axis split.  This choice will improve scalability and performance, all good things, but it will take time.  12 months is the planning figure. The existing persistence tier will not survive that long.

In this situation, applying X axis scaling to the persistence tier can buy time to complete the Y axis refactoring.  The additional cost of the replica DB and storage are for a defined period and the cost rate will decline as the Y axis refactoring is implemented.

Interested in learning more? Contact us, we’ve walked a mile in your shoes.