From Monolithic to Distributed Architecture: A Detailed Inventory System Case Study

Background

The author defines software architecture as an abstract structure composed of components and their dependencies, and explains why choosing an appropriate architecture is essential for solving scalability, maintainability, and efficiency problems.

Purpose of Choosing an Architecture Style

Following the self‑defined "Three‑Better" principle—lower cost, faster releases, and higher stability—the article argues that a good architecture should improve non‑functional requirements such as extensibility and reliability.

Monolithic Architecture

Monolithic systems start with a single deployable package, which is fast for early development but later suffers from code bloat, slow releases, testing difficulty, and poor scalability. Three types are described:

Big‑mud monolith: no layering, tightly coupled modules.

Layered monolith: typical MVC three‑layer structure.

Modular monolith: layered monolith that evolves into separate business modules.

Advantages include simple development, easy testing, and straightforward deployment; disadvantages include large codebase, slow development, difficulty scaling, and stability issues.

Case Study: Inventory System

The inventory system initially provided a single service for stock maintenance, query, and deduction. As business grew, it served B‑side internal platforms and C‑side consumer flows, leading to performance and stability problems during large promotions.

Key events such as a 2015 promotion caused the web management platform to crash due to memory exhaustion, highlighting the need for a more resilient architecture.

Transition to Distributed Architecture

The migration begins with functional splitting—deploying the same code to different clusters for different business groups—followed by business splitting based on domain events (stock initialization, quantity maintenance, deduction, alerts, etc.).

Business splitting guidelines include understanding domain boundaries, minimizing cross‑module dependencies, evaluating impact size, and avoiding unrelated refactoring.

Code Refactoring Example

Original @Service public class SkuMainServiceImpl implements SkuMainService { ... } mixed many responsibilities, violated the Dependency Inversion Principle, and contained large methods.

After refactoring, a new business layer @Service public class SkuMainBusinessServiceImpl implements SkuMainBusinessService { ... } isolates command logic, delegates reads to a read service, writes to a write service, and handles MQ messaging, adhering to CQS and SRP.

CQRS Adoption

The system separates read and write services, using Redis as a fast read cache and MQ for asynchronous write propagation, forming a CQRS‑StockCenter that ensures strong consistency while improving scalability.

Distributed Transactions

The article discusses the difficulty of coordinating transactions across microservices, mentions XA/JTA solutions, and notes their limitations with modern data stores like MongoDB, RabbitMQ, and Kafka.

Conclusion

Architecture decisions must be driven by business goals; the inventory system demonstrates a practical path from monolith to distributed microservices, applying functional and business splitting, CQRS, and careful handling of distributed transactions.