Mastering Microservice Design: 3 Core Principles for Scalable Systems

Good microservice design makes later upgrades and maintenance much easier; otherwise it can become a painful headache.

The following design principles are strongly recommended:

Single Responsibility

High Cohesion

Low Coupling

These three principles are core to object‑oriented design and apply equally to microservice architecture.

1. Single Responsibility

Each microservice should承担 only one responsibility.

For example, a microservice that handles both product category management and shopping cart functionality may seem convenient because the same technology stack and data are used, and the same development team can own it.

However, this creates heavy code coupling between the two functions, leading to maintenance, testing, and deployment difficulties similar to a monolithic architecture.

Therefore, according to the Single Responsibility principle, these should be split into two separate microservices.

2. High Cohesion

Closely related behaviors should be placed together.

Consider two services: Order Management and Order Amount Statistics. The statistics service needs to request data from the order management service to compute prices, taxes, and fees.

If a new tax type is added, both services must be updated, creating tight coupling.

Since the statistics logic is tightly related to orders, it should be merged into the order service, achieving high cohesion by grouping related behavior.

3. Low Coupling

A change in one service should not affect other services.

This principle covers several aspects.

3.1 Hide Internal Implementation

When a statistics function is merged into the order service, its public interface no longer needs to be exposed, preventing accidental misuse and reducing coupling.

3.2 Avoid Shared Codebases

Sharing code libraries can create strong dependencies; upgrading a language version may break services that rely on older APIs.

While complete avoidance is unrealistic, you can mitigate risk by not sharing libraries or by reducing library granularity.

3.3 Avoid Over‑exposing Data

A user service that returns all user details to a shopping‑cart service unnecessarily shares sensitive information such as payment data.

Only basic attributes should be returned, with special data provided via separate interfaces, reducing inter‑service coupling.

3.4 Avoid Database Sharing

Services should obtain data from other services through APIs rather than directly accessing each other's databases, preventing data‑layer coupling.

3.5 Minimize Synchronous Calls

When creating an order, calling many other services synchronously (user, product, payment, inventory, logistics) is risky; a failure in any call aborts the order.

Using event‑driven asynchronous communication is preferable, as synchronous calls can cause network blocking and demand high availability from the called services.

3.6 Avoid Sharing Hardware Infrastructure

Deploying two resource‑heavy services on the same server can cause one to starve the other; balanced hardware planning is essential.

3.7 Avoid Platform‑Specific Technologies

Technologies like Java RMI tie both sides to the same platform, increasing coupling; platform‑independent approaches such as REST are more flexible.