Designing Scalable E‑Commerce Architecture: From Business to Technical Layers

A good software architecture should not only meet business functionality but also address non‑functional requirements such as high performance, high availability, scalability, and extensibility. Architecture consists of business architecture and technical architecture, which must be designed together.

1. Necessity of Architecture Design

Architects emerged with the rise of the internet to handle massive data and high concurrency, prompting companies to recruit dedicated architecture professionals.

Conditions for becoming an architect

It is not advisable for those who are uninterested in architecture, have less than four years of IT experience, or lack proactive initiative to jump straight into architectural work.

Advantages of proper architecture

Better organization of business structure.

Improved extensibility, maintainability, and performance optimization.

Enhanced flexibility for business evolution.

Better handling of big data.

Increased stability, lower cost, and faster iteration.

Key considerations

Architecture must be driven by business needs, selecting technologies that support long‑term growth while ensuring performance does not degrade.

2. E‑Commerce Platform Requirements

Customer needs

Online shopping, online payment or cash on delivery.

Communication with customer service after purchase.

Logistics management and tracking.

Product and logistics rating after receipt.

Requirement mapping

Customer need: Online purchase of goods – Functional: Shopping cart, checkout, member management – Non‑functional: User experience (performance, usability).

Customer need: Online communication with service – Functional: Online customer service – Non‑functional: Real‑time communication capability.

Customer need: Online payment or cash on delivery – Functional: Multiple payment methods – Non‑functional: Security, encryption, flexible payment switching.

Customer need: Product and logistics rating – Functional: Rating system – Non‑functional: Logistics system integration.

3. Business Architecture

The platform can be divided into subsystems: product, shopping, payment, logistics, customer service, and rating. Core subsystems are product, shopping, payment, and logistics; auxiliary subsystems include rating, customer service, and API gateway.

Purpose of business decomposition:

Reduce coupling and improve maintainability and extensibility.

Enable independent deployment of subsystems.

Assign dedicated teams to each subsystem for efficiency.

Protect core services under high load.

Business architecture diagram

4. Technical Architecture Evolution

Basic design (single‑server)

Early small‑to‑medium enterprises often used one server for application, database, and static assets, which quickly hit performance bottlenecks when users exceeded 500,000.

Separating image storage and introducing a cache (e.g., Memcache) improved performance by 1‑2 levels.

Intermediate design (three‑server model)

Typical e‑commerce sites used separate servers for application, database, and NFS file system, plus cache middleware, handling up to 10 million records.

Modern design (clustered, load‑balanced)

Session synchronization across multiple web servers is typically handled by a cache middleware.

Optimized architecture for high concurrency

The design incorporates distributed clustering, load balancing, reverse proxy, message queues, and multi‑level caching, similar to large platforms like Taobao and JD.com.

Key components

Application cluster deployment : Multiple instances behind a load balancer.

Distributed communication : RPC between subsystems such as product, comment, payment, and logistics.

Database clustering : Master‑slave replication with read‑write separation; optional sharding for massive tables.

Message queue : Asynchronous communication for order processing, inventory deduction, and delivery, using technologies like RabbitMQ, ActiveMQ, ZeroMQ, or MSMQ.

Two‑level caching : Local cache for static data, distributed cache for dynamic data, with automatic or manual expiration policies.

Service abstraction (SOA) : Common functionalities extracted as shared services or interfaces for reuse across subsystems.

5. Summary of Platform Architecture

The optimized architecture is organized into four layers: load‑balancing proxy layer, application cluster layer, distributed service layer, and data resource layer. This layered approach provides clear responsibilities, high scalability, low coupling, and leverages load balancing, clustering, distributed services, and caching.

The article aims to provide architectural design ideas and core technologies for architects to reference.