Microservice Design Guidelines: Statelessness, Front‑Back Separation, Business Abstraction, and More

Microservices are an architectural style where applications are built as a collection of independently deployable services, each centered on a specific business capability and capable of using different programming languages and data stores.

While many organizations are moving from monolithic to microservice architectures, blindly following the trend can increase development and operational costs; the goal should be to "decompose as a means, integrate as an end" to improve delivery efficiency and enable sustainable evolution.

The author shares a set of frequently used microservice design references, emphasizing that they are not universal solutions and must be adapted to concrete constraints such as legacy systems.

Guideline 1: Stateless Services – Remove state from services so each instance acts as a pure compute node, enabling rapid horizontal scaling; for example, store session data in a distributed cache.

Guideline 2: Front‑Back Separation – Avoid tightly coupling front‑end and back‑end code; the front‑end focuses on interaction and flexibility, while the back‑end (and microservices) expose stable APIs without handling presentation.

Guideline 3: Business Abstraction – Prefer domain‑driven design (top‑down) over data‑driven design (bottom‑up); first clarify business scenarios, establish a ubiquitous language, and define bounded contexts before splitting services.

Guideline 4: Use‑Case Convergence – Identify service call relationships per business flow and keep the number of services involved in a single use case as low as possible to reduce latency and dependency chains.

Guideline 5: Entity Convergence – When multiple services share the same entity, limit the number of services that synchronize that entity to avoid data‑consistency problems.

Guideline 6: High Cohesion – Design services around cohesive business concepts; identify aggregate roots, keep related entities together, and treat each aggregate root as the minimal service unit.

Type

Unique Identifier

Lifecycle

Read‑Only?

Equality Check

Aggregate Root

Globally unique

Independent lifecycle

No

Identity

Entity

Unique within aggregate

Belongs to aggregate root

No

Identity

Value Object

None

No lifecycle

Yes

Attributes

Guideline 7: Low Coupling – Analyze service call strengths; fewer dependencies mean changes in one service have limited impact on others.

Guideline 8: Vertical Splitting First – From a business‑domain perspective, split services vertically by capability, then consider technical debt before merging.

Guideline 9: Horizontal Splitting Later – From a non‑functional perspective, evaluate isolation, reliability, and scalability; split services to protect critical functions and meet performance requirements.

Guideline 10: Self‑Organization Capability – Teams should own the full lifecycle of their microservices, aligning service boundaries with organizational structure to enable independent decision‑making and loose coupling between teams.

In summary, these practical tips aim to help you design microservices that collaborate effectively; remember that decomposition is a means, not an end, and the ultimate goal is to achieve harmonious integration.

Disclaimer: The material is collected from the internet, copyright belongs to the original authors, and the views expressed are solely those of the authors, not of this public account. The article is for learning and discussion only; please verify the content yourself. If any infringement is found, contact the administrator for removal.