Microservice Design Principles: AKF Split, Front‑End/Back‑End Separation, Stateless Services, and RESTful Communication

1. Introduction

Microservices are an architectural style where a large, complex software application is composed of one or more independent services that can be deployed separately and are loosely coupled. Each microservice focuses on a single task and does it well. The article discusses the key design principles for building such systems.

2. AKF Split Principle

The "Scalability Cube" (AKF) introduces three axes—Y (functionality), X (horizontal scaling), and Z (data partitioning)—to guide the design of scalable microservice architectures.

2.1 Y‑Axis (Functionality)

The Y‑axis splits a monolithic application into multiple services, each responsible for a related set of functions (e.g., order management, customer management). This often follows a Service‑Oriented Architecture (SOA) approach. As the number of services grows, service call relationships become complex, necessitating a service registry or gateway for governance.

2.2 X‑Axis (Horizontal Scaling)

The X‑axis expands capacity by replicating services and data across multiple instances, forming clusters with load balancing. This improves both availability and throughput by adding more service instances as needed.

2.3 Z‑Axis (Data Partitioning)

The Z‑axis partitions data based on criteria such as geography, user ID range, or data hotness, creating isolated yet complete sub‑systems (shards). Common partitioning strategies include by 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 interval, user ID)

Data hotness (e.g., active users, popular items)

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

3. Front‑End/Back‑End Separation Principle

Separating front‑end and back‑end responsibilities clarifies responsibilities and allows each side to be optimized by specialists. Benefits include:

Domain experts can optimize user experience on the front‑end and business logic on the back‑end.

Clearer interfaces lead to simpler, more maintainable APIs.

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

4. Stateless Services

A service is considered stateful if it relies on shared data to complete a transaction; otherwise it is stateless. Stateless services can be scaled dynamically because they do not depend on local state. Migrating session or cache data to a distributed cache enables services to become stateless computation nodes.

5. RESTful Communication Style

RESTful APIs follow a stateless communication principle, leveraging HTTP, JSON, and language‑agnostic protocols. Advantages include:

Stateless HTTP provides strong extensibility and built‑in security (HTTPS).

JSON is lightweight, human‑readable, and search‑engine friendly.

Broad language support and mature frameworks simplify development compared to many RPC solutions.