Understanding the AKF Scale Cube: X, Y, Z Axes for System Scalability and Their Application to Kafka and Redis

AKF Scale Cube, also called AKF Scala Cube, was first presented in "The Art of Scalability" and offers a systematic way to think about scaling distributed systems, which must handle large volumes of data and requests while ensuring availability and fault tolerance.

The core of the AKF Scale Cube consists of three simple axes, each with its own scalability rule. Visualizing the cube as a multidimensional dataset helps illustrate the path from minimal scale (lower‑left‑front) to near‑infinite scalability (upper‑right‑back).

X Axis – Horizontal Replication

Common X‑axis scaling methods:

Web layer: replicate web servers and load balancers.

Application layer: store sessions in browsers or separate object caches to enable horizontal scaling independent of the application.

Database layer: use read‑only replicas for reporting, search, and other read‑only workloads.

Application Scaling

Horizontal scaling solves single‑point‑of‑failure issues and increases capacity by running multiple application instances behind a load balancer; each instance handles 1/N of the traffic. It is technically easy to implement and offers good transaction scalability, but session state distribution and increasing code complexity can become challenges.

Database Scaling

For data stores (databases, MQ, cache), X‑axis scaling addresses data single‑point failures and improves safety by using a primary‑secondary (master‑slave) pattern with automatic failover, or dual‑write clients (less common due to added complexity and consistency concerns).

Advantages: simple, fast to implement, good transaction scalability.

Disadvantages: storage cost, scaling cost, does not solve growing application complexity (addressed by Y‑axis scaling).

Y Axis – Functional Decomposition

Application Scaling

Unlike X and Z axes, which duplicate identical instances, Y‑axis scaling splits an application into multiple distinct services, each responsible for a specific set of related functions (e.g., order management, customer management). Each service owns its own data, improving availability, fault isolation, and organizational scalability. Methods include verb‑based decomposition (e.g., checkout service) or noun‑based decomposition (e.g., customer service), or a hybrid approach.

Database Scaling

Y‑axis scaling also affects data stores: different business domains may use separate databases, Redis instances, or MQ topics; within a single DB, finer‑grained splitting can be done via separate schemas, tables, Redis keys, or MQ topics.

Advantages: higher cache hit rates, improved availability through fault isolation.

Disadvantages: design effort and increased service count add complexity.

Z Axis – Partitioning (Sharding / Pods)

Application Scaling

In Z‑axis scaling each server runs the same code but is responsible for only a subset of the data. A router directs requests to the appropriate partition, and a query aggregator collects results from all partitions. Common routing keys include primary keys or customer types, enabling differentiated SLAs.

Database Scaling

Z‑axis partitioning is typically used for databases: sharding across servers (e.g., MySQL sharding, Redis Cluster) based on user ID ranges, modulo, or geographic boundaries. It improves transaction scalability, fault isolation, cache utilization, and reduces operational costs.

Advantages: each server handles a data subset, boosting cache efficiency, reducing memory/I/O, improving transaction scalability, fault isolation, and latency.

Disadvantages: added application complexity, need for partitioning logic, and does not address overall system complexity (requires Y‑axis scaling).

AKF Applications

Kafka

Splitting Strategy

Kafka topics correspond to Y‑axis functional division, partitions correspond to Z‑axis data sharding, and replica leaders/followers correspond to X‑axis high‑availability replication.

Kafka clusters store records in topics; each topic is backed by a set of partition logs. One replica acts as the leader handling reads/writes, while followers sync the data. If the leader fails, a follower is elected as the new leader. Leader metadata is stored in Zookeeper.

Y‑axis: functional split → Kafka Topic.

Z‑axis: data partition → Kafka Partition.

X‑axis: high‑availability → Partition leader/follower replication.

Data Consistency

Producers can set request.required.acks = 1 for weak consistency (acks from leader only), request.required.acks = 0 for fire‑and‑forget, or request.required.acks = -1 (all) for strong consistency, optionally configuring min.insync.replicas to enforce a minimum number of in‑sync replicas.

org.apache.kafka.common.errors.NotEnoughReplicasException: Messages are rejected since there are fewer in‑sync replicas than required.

Redis

Redis’s single‑instance architecture leads to single‑point failures, limited capacity, and performance pressure, which map directly to the three AKF axes.

Splitting Strategy

Applying AKF:

X‑axis: leader/follower replication for high availability.

Y‑axis: separate Redis instances per business domain.

Z‑axis: sharding data across multiple Redis nodes (e.g., Redis Cluster).

Data Consistency

Strong consistency: writes block until all replicas confirm, using the WAIT command; any replica lag can cause write failures.

Weak consistency: leader acknowledges after its own write, replicas sync asynchronously, offering low latency but risking data loss on replica failure.

Eventual consistency: combine Redis with Kafka as an intermediate layer to ensure durable writes before acknowledging the client.

Alternative approach: RedRock integrates RocksDB with Redis, storing hot data in memory and cold data on disk, providing a 100 % Redis‑compatible solution with persistent storage.

References

The Scale Cube – https://akfpartners.com/growth-blog/scale-cube

Splitting Applications Or Services For Scale – https://akfpartners.com/growth-blog/splitting-applications-or-services-for-scale

Splitting Databases For Scale – https://akfpartners.com/growth-blog/splitting-databases-for-scale

Redis Replication – https://redis.io/topics/replication