Designing a Scalable E‑Commerce System with Microservices, DDD, and Distributed Transactions

Microservice Design for an E‑Commerce System

When an interview asks what happens in microservices after a purchase succeeds, we start by defining four basic modules: User, Product (with inventory), Order, and Payment, illustrated with a simple diagram.

These modules form the foundation of the system, and a basic order flow diagram shows their interactions.

To split services properly, we adopt Domain‑Driven Design (DDD). DDD recommends four layers: Infrastructure, Domain, Application, and Interfaces.

Infrastructure

Domain

Application

Interfaces

Applying DDD to microservices, we focus on defining bounded contexts and strategic modeling, resulting in five domains: Sales, Product, User, Order, and Payment.

Sales Domain

Product Domain

User Domain

Order Domain

Payment Domain

After domain definition, we draw a context‑mapping diagram to clarify boundaries and relationships.

We then create a simple sequence diagram for the order process, covering the involved domains.

For the microservice technology stack, we compare Dubbo and Spring Cloud, concluding that Spring Cloud offers a more complete solution for modern microservice ecosystems.

Understanding the pros and cons of microservices is essential. Benefits include strong modular boundaries, independent deployment, and technology diversity, while challenges involve distributed complexity, eventual consistency, and operational overhead.

CAP and BASE Theories

In distributed systems, the CAP theorem forces a trade‑off between Consistency, Availability, and Partition tolerance. Most systems prioritize Availability and tolerate eventual consistency, as described by the BASE model (Basically Available, Soft state, Eventually consistent).

Distributed Transaction Solutions

We evaluate transaction strategies and discard XA two‑phase commit and Alibaba GTS due to performance and maturity concerns. The remaining options are MQ‑based transactions (RocketMQ) and TCC.

MQ transaction flow (RocketMQ) uses asynchronous messages to decouple the two branches of a transaction.

TCC implements Try‑Confirm‑Cancel phases, mapping to lock‑commit‑rollback in traditional databases.

Both approaches achieve eventual consistency while improving performance under high concurrency.

Circuit Breaker, Rate Limiting, and Isolation

To protect the system, we adopt Hystrix, which integrates circuit breaking, isolation, rate limiting, and fallback mechanisms.

Hystrix workflow includes command creation, execution, circuit state checks, fallback handling, and metrics reporting.

Centralized Configuration Center

We recommend using a centralized configuration service (e.g., Spring Cloud Config, Apollo) to manage runtime parameters without redeploying services.

Apollo combines pull and push modes for high availability.

Monitoring and Tracing

Distributed tracing is crucial for debugging. Tools like SkyWalking, Zipkin, Pinpoint, and CAT provide end‑to‑end visibility. SkyWalking is chosen for its non‑intrusive Java agents, method‑level granularity, Elasticsearch storage, and strong performance.

Capacity Planning and Deployment

Before production, we estimate average and peak QPS, perform load testing to determine single‑node limits, and calculate required instance counts with redundancy.

We also consider auxiliary components such as monitoring, API gateways, unified exception handling, documentation, containerization, and service orchestration.