How a Large‑Scale E‑Commerce Platform Uses a Middle‑Platform Architecture for Scalability

Overall Architecture Principles

The architecture follows a "large middle platform + small front‑end" approach. The business middle platform adopts Domain‑Driven Design (DDD) to build SaaS‑style business capabilities that evolve continuously. Platformization enables business isolation, supporting multiple business models and easy customization. Front‑end and back‑end are separated, with a service access layer handling routing and adaptation. Native sharding, message decoupling, distributed caching, and elastic scaling support high‑concurrency big‑data scenarios.

System Logical Architecture Diagram

The following sections describe each component.

E‑Commerce Middle Platform

The middle platform is divided into a foundational capability layer and a platform product layer. The foundational layer provides stable, converged business models and services (akin to a DAO). The product layer uses workflow orchestration to combine these capabilities into solutions for both common and personalized needs. For example, transaction design shows that most transactions involve domains such as inventory, discounts, and pricing, which can be abstracted as atomic capabilities with extension points for special scenarios.

The product layer composes these atomic capabilities into services for various transaction types (fixed price, auction, cash‑on‑delivery, pre‑sale, etc.).

Service Access Layer

The service access layer connects front‑end products with middle‑platform services. It is essentially a Spring Boot web application that performs parameter conversion, routing, service invocation, and result packaging. It must enforce interaction standards, routing conventions, project structure, load‑balancing, cross‑origin, and security considerations.

Common Base Components

Reusable components are abstracted for broader use and possible open‑source release:

Data Access Component: abstracts sharding, read/write separation, and master‑slave switching.

Message Middleware Component: encapsulates various MQ solutions (ActiveMQ, RabbitMQ, RocketMQ, Kafka, cloud‑provided services) to hide vendor differences.

Address Library Component: provides unified geographic address services, crucial for international expansion and multi‑level domestic addressing.

Cloud Services & Container Layer

For small teams lacking extensive ops expertise, using mature cloud services (e.g., Alibaba Cloud ECS) and Docker containers reduces operational overhead and accelerates development.

Business Front‑End Products

iOS, Android, H5, PC sites, and WeChat/Alipay mini‑programs constitute the front‑end layer, built according to business shape and product positioning.

Stability and Security Assurance

During peak events (e.g., Double‑11), traffic can surge dozens to hundreds of times. Monitoring of system metrics, rate limiting, and exception handling becomes critical. The stack includes:

Sentinel: lightweight distributed flow control, circuit breaking, and system protection.

Dubbokeeper: enhanced Dubbo monitoring and management.

Pinpoint: zero‑intrusion tracing of request call chains via JavaAgent.

Telegraf + InfluxDB + Grafana: real‑time business metric collection and visualization.

Engineering Structure

Logical modules map to physical sub‑projects (e.g., Maven modules). The number of sub‑systems depends on team size; a small team may consolidate middle‑platform services into 3‑4 projects, while larger organizations may allocate one team per business domain.

Why Use Business Middle‑Platform for Transaction Systems

As business scales, monolithic architectures become bottlenecks. A middle‑platform isolates core transaction capabilities, provides extension points for personalized scenarios, and improves development efficiency and system stability.

General Transaction Business Flow

Two representative flows are shown: order creation and reverse refund. Both involve domains such as pricing, discounts, inventory, order splitting, payment, purchase limits, delivery, timeout handling, and after‑sale services.

Transaction Business Middle‑Platform Architecture

Applying the 80/20 principle, core capabilities are abstracted into a foundational layer, which is then orchestrated into a platform product layer exposing unified services. The transaction system also depends on auxiliary services such as membership, product, shop, inventory, discount, payment, and logistics.

Overall Design

Domain models follow DDD principles, requiring deep business understanding and future foresight. Core class diagrams illustrate major business domains without excessive detail.

The PA (Presentation/Application) layer exposes DTOs and event messages, allowing front‑end services to consume transaction changes.

Core Service Design

The service access layer mainly wraps micro‑service calls (Dubbo) into RESTful endpoints; the core services themselves are micro‑services.

Core Link Sequence Design

A simplified order‑to‑payment flow illustrates the main call chain, highlighting where asynchronous processing, caching, retry, timeout, idempotency, and consistency measures are applied.

The technical design addresses classic distributed high‑concurrency challenges; further details will be covered in dedicated articles.