Four Microservice Architecture Design Patterns Explained

Microservices are a core component of large‑scale systems. This article analyzes four common microservice architecture designs, discusses their trade‑offs, and suggests suitable scenarios for each.

1. Shared‑Database Design

This scheme lets multiple services operate on the same data source, offering simplicity and strong data consistency.

Order service – creates orders

Product service – manages products

Inventory service – deducts stock

All services directly access the same MySQL database:

Order Service
|
Product Service
|
Inventory Service
|
MySQL Database

Pros: easy to implement, consistent data. Cons: tight coupling, hampers independent evolution, violates microservice autonomy. Suitable for transition phases or scenarios demanding strict consistency.

2. Aggregation Design

Each service provides its own capability; an aggregation layer composes data and returns a complete result to the front‑end.

Example – product detail page needs:

Product information

Inventory information

Comments

Discount information

Without aggregation the client must make multiple calls:

Client → Product Service → ↓
Client → Inventory Service → ↓
Client → Comment Service → ↓
Client → Discount Service

With aggregation the client calls a single endpoint: <code>Client → Product Aggregation Service → ↓ ↓ Product Service Inventory Service Comment Service Discount Service</code> Benefit: only one request from the client. 3. Proxy (Gateway/BFF) Design A gateway, BFF, or unified proxy exposes a single entry point, routing internally to individual microservices. It hides internal complexity, improves security and maintainability, and simplifies authentication, rate‑limiting, and monitoring. Typical components: Spring Cloud Gateway Nginx Kong Architecture example: <code>User → API Gateway → ↓ ↓ Order Service Product Service User Service Payment Service</code> 4. Asynchronous Messaging Design Services communicate via message queues, achieving loose coupling and event‑driven collaboration. Common middleware: Kafka RocketMQ RabbitMQ Architecture example: <code>Order Service → | → Message Queue (MQ) → | → Inventory Service → | → Points Service → | → Notification Service</code> Advantages: peak‑shaving, higher throughput; suitable for high‑concurrency, strong decoupling, and eventual‑consistency scenarios such as order, inventory, and payment processing. Drawbacks: increased system complexity, need to handle duplicate messages, ordering, and idempotency. In real projects the four schemes are often combined to balance performance, flexibility, and consistency.