Optimizing Large‑Scale E‑Commerce Site Architecture: Business Splitting, Clustering, Caching & SSO

This is the second article in the power‑grid website architecture case series, focusing on architecture analysis, optimization, business splitting, application cluster design, multi‑level caching, and distributed session management.

5. Website Architecture Analysis

Based on the estimation, several issues arise:

Deploying a large number of servers (up to 30 web servers) that are only needed during flash sales, leading to waste.

All applications are deployed on the same server, causing severe coupling and requiring vertical and horizontal splitting.

Significant code redundancy across applications.

Session synchronization across servers consumes considerable memory and bandwidth.

Frequent database access creates massive load on the database.

Typical optimizations for large websites include business splitting, application cluster deployment (distributed deployment, clustering, load balancing), multi‑level caching, single sign‑on (distributed session), database clustering (read/write separation, sharding), service‑oriented architecture, message queues, and other technologies.

6. Website Architecture Optimization

6.1 Business Splitting

Vertical splitting based on business attributes creates subsystems such as product, shopping, payment, review, customer service, and interface (e.g., ERP, SMS) subsystems.

Subsystems are classified into core (product, shopping, payment) and non‑core (review, customer service, interface) systems.

Benefits of business splitting include assigning dedicated teams to each subsystem, reducing coupling, improving extensibility, and allowing independent deployment to avoid single‑point failures.

Level definitions enable graceful degradation during traffic spikes, protecting critical applications.

Architecture diagram after splitting:

Reference deployment plan 2:

(1) Deploy each application separately as shown in the diagram.

(2) Combine deployment of core and non‑core systems.

6.2 Application Cluster Deployment (Distributed, Cluster, Load Balancing)

Distributed deployment places each split application on its own server and enables remote communication via RPC.

Cluster deployment ensures high availability by deploying at least two servers per application.

Load balancing is essential for high‑availability systems; applications use load balancers, distributed services incorporate built‑in balancing, and relational databases achieve HA through primary‑secondary replication.

Cluster deployment architecture diagram:

6.3 Multi‑Level Caching

Caches are generally categorized by location: local cache and distributed cache. This case uses a two‑level cache design where the first level is local and the second level is distributed (page and fragment caches are finer‑grained variations).

The first‑level cache stores immutable or slowly changing data such as dictionaries and hot items; the second‑level cache stores all other cached data. If the first‑level cache misses or is unavailable, the second‑level cache is consulted, and if that also misses, the database is accessed.

A typical cache‑to‑database ratio is 1:4 (theoretically 1:2).

Cache expiration strategies based on business characteristics include automatic expiration and trigger‑based expiration.

6.4 Single Sign‑On (Distributed Session)

When multiple subsystems are independently deployed, session management becomes inevitable. Common approaches include session synchronization, cookies, and distributed sessions; e‑commerce sites typically adopt distributed sessions.

Distributed sessions can be extended to a full single sign‑on or account management system.

Process description:

(1) On first login, user session information (user ID and details) is written to the distributed session, using the user ID as the key.

(2) On subsequent logins, the distributed session is checked; if missing, the user is redirected to the login page.

(3) A cache middleware such as Redis is recommended for implementing distributed sessions, providing persistence to recover sessions after failures.

(4) Session timeout can be set (e.g., 15 minutes) after which the session expires automatically.

(5) Combining cache middleware enables robust distributed session simulation.