From Monolithic to Distributed Architecture: A Case Study of an Inventory System

Software architecture is an abstract structure composed of components and their dependencies; choosing the right style helps reduce cost, speed releases, and improve stability.

Monolithic Architecture includes three types—big‑muddy, layered, and modular—each with advantages such as simple development, testing, and deployment, but also drawbacks like code bloat, slow development, and poor scalability that become evident as business grows.

The inventory system started as a single monolith with API and web services, which worked well for early rapid iteration but later suffered from memory exhaustion, high latency, and stability issues during large promotional events.

Distributed Architecture offers high availability, scalability, fault tolerance, and easier maintenance, addressing the monolith’s shortcomings. However, it introduces challenges such as increased service complexity, distributed transaction management, and potential latency.

The migration follows three steps: (1) functional splitting by grouping services per business domain; (2) business splitting using domain‑driven boundaries (e.g., inventory initialization, quantity maintenance, deduction, alerts); (3) refactoring the service layer by applying CQS (Command‑Query Separation) and SRP (Single Responsibility Principle) to break God classes.

Example code shows the original @Service public class SkuMainServiceImpl implements SkuMainService { ... } with tightly coupled dependencies, and the refactored version @Service public class SkuMainBusinessServiceImpl implements SkuMainBusinessService { ... } that separates read/write services, injects dedicated read/write components, and moves business logic out of the service layer.

Adopting CQRS, the system separates command (write) and query (read) paths: write services update Redis and emit MQ messages for asynchronous persistence, while read services serve data directly from Redis, improving stability and performance.

Distributed transactions are discussed, noting that traditional XA‑based solutions are heavyweight and often unsupported by modern data stores; the article suggests using eventual consistency patterns and compensating actions where appropriate.

Finally, the article invites readers to discuss, ask questions, and join a community for deeper architectural insights.