Understanding Microservice Architecture: From Traditional SOA to Modern Practices

Microservice architecture has become a hot topic, yet many still lack a clear understanding of what it truly entails; this article, based on the author’s experience with large‑scale internet systems, explores the concept, its evolution, and practical design considerations.

Traditional SOA Architecture

Traditional SOA relies on an Enterprise Service Bus (ESB) to expose coarse‑grained services from legacy systems, handling complex protocols (WebService, HTTP, FTP, etc.) and data serialization, which leads to high integration cost, single‑point‑of‑failure risks, and limited horizontal scalability.

New‑Generation SOA Architecture

Modern SOA eliminates the heavy ESB, using lightweight protocols (typically HTTP/JSON) and allowing services to be independently deployed, which improves flexibility, scalability, and reduces coupling.

Service Design Approaches

1. Business‑system‑oriented services : Extract business logic from monoliths into coarse‑grained services (e.g., product‑detail or order services) that may lead to tangled dependencies if not carefully designed.

2. Domain‑oriented (fine‑grained) services : Build services around specific business concepts (e.g., a user service) that own exclusive access to their data tables, enhancing encapsulation and rule enforcement.

3. Infrastructure‑oriented services : Expose hardware‑level capabilities such as SMS, storage, or caching as services, often backed by clustered or multi‑router implementations for reliability.

Deep Dive into Microservices

Microservices, popularized by Martin Fowler in 2014, embody two core ideas: simple connectivity (lightweight protocols, JSON payloads, no central ESB) and distributed management (separate business, data, and physical resources). Traditional ESB‑based services do not satisfy these criteria.

Examples include a detailed e‑commerce inventory microservice that distinguishes physical, virtual, promotional, shared, and frozen stock, and provides a unified “sellable inventory” calculation.

The inventory microservice demonstrates several benefits:

Unified business rules : A single entry point encapsulates complex stock calculations, isolating rule changes within the service.

Consistent data model : The service exclusively accesses four inventory tables, preventing ad‑hoc schema changes by other applications.

Internal optimizations : Centralized caching and real‑time updates improve performance and consistency.

Horizontal scalability : Deployed on virtual machines or containers, the service can be elastically scaled during traffic spikes.

Microservice System Hierarchy

A complete microservice ecosystem is layered: foundational system services (e.g., messaging, storage) at the bottom, shared domain services (e.g., product, user, order) in the middle, and business‑specific services on top. Calls flow downward, while same‑level services remain orthogonal.

Microservice System Architecture

In a large B2C e‑commerce platform, the upper layer consists of various business applications, while the lower layer contains numerous application and infrastructure services, forming a typical microservice architecture that leverages cloud‑native container deployment for elasticity.

Overall, microservices simplify technical implementation through simple connectivity and reduce business coupling via distributed management, making them a natural choice for complex, high‑traffic internet systems.