16 Essential Principles for Designing, Implementing, and Governing Microservices

1. Microservice Planning

Principle 1 – Business‑capability‑driven partitioning : Follow Conway’s law; the communication cost of a team grows as n·(n‑1)/2. Large organizations should split work into autonomous, self‑governing teams and map each capability to a separate microservice.

Principle 2 – Domain‑Driven Design (DDD) : Abstract the business, analyse processes, identify bounded contexts, build domain models and map them to services. Avoid anemic domain objects and over‑coupling. Distinguish entities, value objects, aggregate roots, domain services and domain events.

2. Microservice Design

Principle 3 – Single‑Responsibility : Each service should expose a single, well‑defined business function and remain orthogonal to other services.

Principle 4 – High Cohesion : A service must be independently deployable, testable and contain at least one complete business entity with its full operations. Strongly related data and behaviour stay together.

Principle 5 – Low Coupling : Avoid exposing internal data, sharing databases, and synchronous calls. Prefer asynchronous, event‑driven communication and keep dependencies unidirectional.

3. Microservice Implementation

Principle 6 – Stateless Services : Move shared state to dedicated stateful data services (e.g., distributed caches, databases). Compute services become pure stateless nodes, enabling elastic scaling.

Example: migrate in‑process Session or local cache to a distributed cache (e.g., Redis) so that service instances remain interchangeable.

Principle 7 – High Availability : Integrate middleware such as Sentinel for rate limiting, circuit breaking and degradation to improve resilience.

Principle 8 – Observability : In addition to system metrics, define business‑level monitoring indicators (e.g., order‑processing latency, error‑rate per domain event).

Principle 9 – Centralised Configuration : Store all service configuration in a configuration centre (e.g., Nacos, Apollo) to enable version control and dynamic updates.

4. Microservice Invocation

Principle 10 – Avoid Distributed Monolith : Enforce unidirectional calls and prevent circular dependencies among services.

Principle 11 – Asynchronous Decoupling : Use message queues (e.g., Kafka, RocketMQ) to achieve traffic‑spike smoothing, eventual consistency and reduced latency.

Principle 12 – Backend‑For‑Frontend (BFF) : Introduce a BFF layer to isolate front‑end‑specific concerns, keeping core services cohesive and reusable.

5. Microservice Release

Principle 13 – Safe Release (Three‑blade strategy) : Deploy canary versions, continuously monitor health metrics, and retain the ability to roll back instantly.

6. Microservice Governance

Principle 14 – Continuous Evolution : Recognise architectural decay (e.g., frequent merge conflicts, tight coupling, performance bottlenecks) and split or refactor services accordingly.

Principle 15 – AKF Expansion Cube : Extend services along three axes:

X‑axis – Horizontal scaling (add machines or instances).

Y‑axis – Functional / business splitting (finer‑grained services, isolation of heavy‑weight OLTP vs. batch jobs, core vs. non‑core workloads).

Z‑axis – Data partitioning (sharding by time, user‑id, etc., using middleware such as Sharding‑JDBC or Mycat).

7. Microservice Decommission

Principle 16 – Service Retirement : Clean obsolete code, de‑register environments, and reclaim compute/storage resources to reduce maintenance cost.