Four Core Principles for Designing Microservice Architectures

Evolution of Microservice Architecture

Microservice architecture emerged as enterprises sought greater flexibility and faster response to changing requirements. Early systems began as monolithic applications, then added vertical scaling with load balancers, evolved to Service‑Oriented Architecture (SOA) for integration, and finally adopted microservices to improve independent development, management, and efficiency.

Benefits of Microservice Architecture

Each microservice component is simple, flexible, and can be deployed independently, eliminating the need for a large application server.

A small, focused team can own a service, leading to higher efficiency and reliability.

Microservices are loosely coupled and highly cohesive, making on‑demand scaling straightforward.

The architecture is language‑agnostic, allowing teams to choose the most suitable language and tools for business goals.

Design Principles for Microservice Applications

AKF Splitting Principle

Derived from the AKF scalability cube in The Art of Scalability , three expansion dimensions are defined:

X‑axis : Horizontal replication – running multiple instances behind a load balancer.

Z‑axis : Data partitioning – e.g., separating clusters by geographic region for a ride‑hailing platform.

Y‑axis : Service splitting – dividing the system by distinct business capabilities.

Example: a ride‑hailing platform first scales clusters, then partitions by region, and finally splits into passenger, driver, and payment services, each with independent characteristics and on‑demand scaling.

Front‑End/Back‑End Separation

The principle advocates separating front‑end code (HTML, CSS, JavaScript) from back‑end services, preferably via physical deployment separation. This avoids monolithic templates such as JSP that mix Java, JS, HTML, and CSS.

Front‑end and back‑end experts can optimize their domains, improving user‑experience quality.

Clearer interfaces and models simplify back‑end API maintenance.

Front‑end can be reused across web UI, mobile apps, etc., without changing back‑end services.

Stateless Service

State is defined as data that must be shared across multiple services to complete a transaction. Services that rely on such data are "stateful"; those that do not are "stateless". The principle recommends moving business logic to stateless compute services while storing shared state in dedicated stateful data services such as distributed caches.

Example: local in‑memory or session caches are migrated to a distributed cache, allowing compute services to scale dynamically without cache‑synchronization concerns.

RESTful Communication Style

RESTful HTTP is recommended because it provides a stateless protocol with strong extensibility, mature HTTPS security, lightweight JSON serialization, and language‑agnostic frameworks.

Stateless HTTP offers inherent scalability and mature security options.

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

All major languages have mature RESTful API frameworks, giving a richer ecosystem than many RPC solutions.

In special cases, RPC frameworks such as Thrift, Avro‑RPC, or gRPC may be required, but RESTful APIs suffice for most scenarios.

Issues Introduced by Microservice Architecture

Tracking changes in dependent services is difficult; interface documentation can become outdated, and unready services hinder feature verification.

Duplicate development across teams, systems, and languages leads to redundant effort.

Distributed architecture amplifies problems such as handling distributed transactions and dealing with unstable dependencies.

Operational complexity rises sharply due to the large number of services, processes, and monitoring requirements.

Mitigation measures include documentation management, service governance, service simulation tools, unified authentication, unified configuration, unified logging, distributed analysis, global transaction solutions, asynchronous‑to‑synchronous patterns, continuous‑integration platforms, and unified monitoring platforms. Organizations typically build a comprehensive microservice application platform tailored to their specific business needs.