AKF Partners

Abbott, Keeven & Fisher Partners Partners in Growth

Growth Blog

Advice on how to fix broken $#*!

How to Scale a Read Subsystem

April 3, 2017  |  Posted By: AKF

Many SaaS systems have a large part of the system dedicated to reading or searching for information. This read or search may be implemented in an ecommerce site as a product/inventory search based on keywords, or in a content site it may be a implemented as an unstructured string search or regular expression search against all indexed content.

In high transaction sites, this activity can be extremely taxing and even cost prohibitive on the primary database should be considered a great target for disaggregation along the Y axis of our scale cube as we describe in our database scaling post.

The AKF scale cube can be applied to read/search subsystems to create multiple dimensions of splits that will allow for near infinite scale. Below is our cube diagram depicting the three dimensions for scaling a read or search subsystem.

As with our past cubes, the X axis is the balancing of transaction load against multiple clones. This allows the system to scale in terms of transactions but not necessarily the size of data.

The Y axis is a split along function or service. While the read/search subsystem split is a Y axis split of the original database, we can recursively split this by creating read subsystems specific to a product catalog, userspecific information, order history, archived content, current content, recommended content, and on and on.

The Z axis is our modulus, lookup function or indiscriminate function split.

Let’s look at the X and Z axis to describe a physical system that can be easily scaled for reads. This physical architecture would be comprised of aggregators, load balancers, and an NxM matrix where N systems hold 1/Nth of the data and M storage systems each get 1/Mth of your transactions along those N dimensions. The storage subsystems don’t have to be relational databases, they could be in memory data stores such as memcached or Berkeley DB instances.

Read or search requests are load balanced to one of X (X scales with the number of requests being made) aggregators, each of which subsequently make N requests of the N unique data sets through a load balancer to one of M systems within the N data tiers. The Nunique responses are aggregated and sorted and returned to the customers.

click to enlarge

The benefit of such a system is that you can scale N easily with the number of items listed and M with the number of transactions requested. If N is sized appropriately, the items can all be returned from memory thereby further increasing transaction speed.

If you want higher speed and even greater fault tolerance, you can further split these read subsystems along the Y axis as described previously in this document.

Sub Arch

Next: PDLC or SDLC