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

Before discussing architecture styles, the article clarifies what architecture is—a high‑level abstraction composed of components and their dependencies—and why it is needed to reduce cost, accelerate releases, and improve system stability.

It introduces the "three‑better" principle (lower cost, faster releases, better stability) and explains that a good architectural style should satisfy functional requirements while enhancing non‑functional ones such as scalability and reliability.

The monolithic architecture section describes three types—big‑muddy‑monolith, layered monolith (e.g., MVC), and modular monolith—listing their advantages (simple development, easy testing, straightforward deployment, effortless horizontal scaling) and disadvantages (code bloat, complexity, slower development, long deployment cycles, difficulty scaling, stability issues, reliance on outdated tech).

A concrete inventory‑system case is presented: initially a single service providing API and web management, which performed well for early rapid iteration but later suffered memory exhaustion and latency during high‑traffic promotions, prompting a move to a distributed design.

The distributed architecture section outlines its benefits (high availability, scalability, fault tolerance, readable business code, easier maintenance) and drawbacks (increased service count, higher learning curve, technology‑stack upgrades, distributed transaction handling, RPC overhead).

To transition, the article details a three‑step approach:

Functional splitting: isolate services per business function by deploying the same interface with different group aliases.

Business splitting: define clear business boundaries, minimize cross‑module dependencies, evaluate impact, and avoid altering business logic during refactoring.

Technical splitting: refactor the service layer using CQS (Command‑Query Separation) and SRP (Single‑Responsibility Principle), extract business logic into a dedicated business layer, and introduce adapters for clean interfaces.

Code excerpts illustrate the original @Service public class SkuMainServiceImpl implements SkuMainService { ... } with tightly coupled dependencies and a large method editorSaveProuct , followed by the refactored version @Service public class SkuMainBusinessServiceImpl implements SkuMainBusinessService { ... } that delegates read/write responsibilities to separate services, thereby reducing coupling and improving testability.

After business layer refactoring, the article discusses further separation of read and write services using CQRS, recommending to split reads first for stability. It presents a CQRS‑StockCenter design where write commands update Redis and async MQ messages persist data to MySQL, achieving strong consistency for inventory queries.

The final part addresses distributed transactions, explaining why traditional two‑phase commit (XA) is often unsuitable for modern polyglot stacks and suggesting alternative patterns such as eventual consistency and compensating actions.

Overall, the article demonstrates how to evolve an inventory system from a monolithic architecture to a robust, distributed, CQRS‑based solution, emphasizing architectural principles, practical code refactoring, and trade‑offs.