Key Technologies and Design Patterns for Implementing Microservices: Architecture Characteristics, Patterns, and Data Consistency

Microservice architecture has become a focal point for developers, and this article shares the key characteristics, typical design patterns, service decomposition strategies, and data consistency techniques derived from ZhaiZhai's practical experience.

Microservice Architecture Characteristics

Proposed by Martin Fowler in 2014, microservices are a collection of small, business‑domain‑oriented services. Each service is vertically split according to distinct business functions, forming a business‑centric architecture where deeper domain knowledge leads to more reasonable service boundaries.

The ZhaiZhai second‑hand trading platform includes user, product, transaction, search, and recommendation modules, each of which can be vertically split into separate microservices. Horizontally, each function can be divided into gateway, business‑logic, and data‑access layers (DB/Cache).

The typical microservice stack consists of a gateway, aggregation (business‑logic) layer, atomic data‑access layer, data stores, a service registry, and a configuration center. The gateway handles request entry, the aggregation layer processes business logic, and the atomic layer provides ORM, sharding, and storage abstraction.

Architecture Design Patterns and Practice Cases

Four representative patterns are highlighted:

Chain pattern – the APP request passes through the gateway, calls Service 1, which synchronously calls Service 2, then responses flow back through Service 1 to the gateway and finally to the APP. Common in transaction scenarios.

Aggregator pattern – the APP request reaches the gateway, then the aggregation layer concurrently or sequentially invokes multiple services, aggregates their results (e.g., time‑sorted), and returns the combined response to the gateway and APP.

Data‑sharing pattern – multiple services (e.g., product query and product update) share the same underlying product data.

Asynchronous message pattern – instead of waiting for all synchronous calls, the APP request is persisted to a message queue, immediately acknowledges the APP, and downstream services consume the queue asynchronously, improving throughput for high‑traffic scenarios.

Data Final Consistency Practices

In microservice environments, data is distributed, making traditional local transactions infeasible. The article discusses two scenarios: (1) simple asynchronous calls with message‑queue compensation, and (2) synchronous calls where distributed transactions are replaced by compensating actions. The key ideas are recording the call chain, providing idempotent compensation interfaces, and using a proxy in the aggregation layer to log request parameters before invoking atomic services.

The atomic layer must expose both normal and idempotent compensation interfaces. Distributed transaction management relies on three tables: a transaction‑group table (e.g., A→B→C), a transaction‑call‑group table storing request context for each step, and status fields ("started", "failed", "succeeded"). A background compensating service scans the call‑group table for failed transactions and triggers asynchronous compensation.

If the distributed transaction itself fails, the system logs the error and alerts via SMS for manual intervention.

Case Study: ZhaiZhai Aggregator Pattern

The ZhaiZhai platform aggregates product, search, and recommendation services. The APP request passes through the gateway to the aggregation layer, which invokes the atomic services for product, transaction, and recommendation, merges their results, and returns the combined response to the APP.

Author Bio

Sun Xuan, Head of ZhaiZhai Infrastructure, former Chairman of the 58 Group Technical Committee, and author of the "Architecture Beauty" public account.