Design Principles of Microservices: AKF Scalability Cube, Front‑End/Back‑End Separation, Stateless Services, and RESTful Communication

1. Introduction

Microservices is an architectural style where a large complex application consists of one or more independent, loosely coupled services that can be deployed separately, each focusing on a single task. The key design principles include the AKF splitting principle, front‑end/back‑end separation, stateless services, and RESTful communication.

AKF Splitting Principle

Front‑End/Back‑End Separation Principle

Stateless Service

RESTful Communication Style

2. AKF Splitting Principle

The "Scalability Cube" (AKF) models scalability along three axes—Y (function), X (horizontal scaling), and Z (data partition)—to address capacity and availability challenges as systems grow.

2.1 Y Axis (Function)

The Y axis divides a large application into multiple services, each handling a related set of functions (e.g., order management, customer management). This is commonly realized through Service‑Oriented Architecture (SOA). An e‑commerce platform can be split into distinct services as shown below.

As the number of services grows, service call relationships become complex, making it difficult to add new features without chaotic dependencies. Typically, a service registry and gateway are introduced for service governance, resulting in the architecture illustrated below.

2.2 X Axis (Horizontal Scaling)

The X axis follows the simple idea of "adding machines" to solve capacity and availability problems. It involves running multiple instances of each microservice, forming a cluster with load balancing to improve both availability and throughput.

2.3 Z Axis (Data Partition)

The Z axis focuses on partitioning systems based on unique requester or user requirements, creating isolated yet complete subsystems. An analogy is a car manufacturer establishing a separate factory in China to serve the local market, mirroring the U.S. plant.

Common Z‑axis solutions include:

1. Cell Architecture

In distributed service design, a cell is a self‑contained loop that satisfies all business operations for a specific partition. Adding Z‑axis partitioning to a Y‑axis SOA makes service selection deterministic per cell, as shown below.

2. Data Partitioning

For performance and security, a complete dataset is divided into subsets (shards) based on dimensions such as data type, range, hotness, or read/write separation. For example, a ride‑hailing platform may partition data by city.

Data type (e.g., business type)

Data range (e.g., time period, user ID)

Data hotness (e.g., user activity, product popularity)

Read/write split (e.g., product description vs. inventory)

Example: Meituan or Didi partitioning data by city.

3. Front‑End/Back‑End Separation Principle

Separating responsibilities so that the front‑end handles presentation while the back‑end handles business logic leads to clearer interfaces and easier maintenance.

Specialists can optimize their domains, improving user experience on the front‑end.

Clearer interaction model reduces API complexity and eases maintenance.

Multiple front‑ends (WeChat H5, PC, Android, iOS) can consume the same back‑end services without changes.

4. Stateless Service

A "state" is data shared among multiple services to complete a transaction; services that depend on such data are stateful, otherwise they are stateless.

Traditional in‑process caches or session data should be migrated to distributed caches, turning services into stateless compute nodes. After migration, services can scale dynamically without worrying about cache synchronization, which is crucial for business expansion.

5. RESTful Communication Style

While the principle advocates a "stateless communication" model, RESTful APIs are recommended for their many advantages:

Stateless HTTP provides inherent scalability; HTTPS adds mature security.

JSON payloads are lightweight, human‑readable, and search‑engine friendly.

Language‑agnostic; most popular languages offer mature RESTful frameworks, often more robust than many RPC ecosystems.