Design and Architecture of a Cloud Shopping Cart System
The article explains the functional purpose, early evolution, layered and clustered design, distributed technical architecture, caching, asynchronous checks, heterogeneous storage, payment solutions, and anti‑bot measures of a cloud‑based shopping cart, highlighting stability, performance, elasticity, and fault‑tolerance.
The main purposes of a shopping cart are: (1) similar to traditional stores, it allows users to select multiple items for checkout; (2) it serves as a temporary favorites list; (3) for merchants, it is one of the best places for promotion.
Like traditional stores, convenient for users to select multiple items for checkout.
Acts as a temporary favorites list.
For merchants, the shopping cart is a prime spot for upselling.
Early
ERP split
Business service split
WCS split
Shopping Cart Functional Module Overview
Layer Design
Cluster Design
The cloud shopping cart is designed at the application layer with three horizontal layers—Interaction Layer, Business Assembly Layer, and Basic Service Layer—each possibly composed of one or more clusters.
Interaction Layer: includes the shopping page (add to cart, view cart) and the checkout page (checkout, buy now, submit order for payment).
Business Assembly Layer: provides standard shopping‑cart processes and non‑standard extensions.
Basic Service Layer: encapsulates data distribution from peripheral systems and core functional services.
At the cluster level, two vertical clusters are defined: Shopping‑Cart Cluster and Settlement‑Cart Cluster.
Shopping‑Cart Cluster: handles high traffic and stores highly sensitive user information that must not be lost.
Settlement‑Cart Cluster: stores auxiliary settlement information (e.g., payment configuration) that is less sensitive and can be recomputed.
Technical Architecture Design
The system adopts a distributed design to achieve the following goals:
Stability: provide 24/7 reliable service.
High Performance: ensure high throughput and low latency even under heavy concurrency.
Elasticity: resources can be smoothly scaled (e.g., using VMs or containers) to meet demand spikes.
No Single Point of Failure: eliminate any component that could cause a total outage.
Fault Masking Automation: automatically isolate and handle failures in network, application, or database layers.
Three‑Tier Cache
Asynchronous Check
Heterogeneous Storage
Advantages: simple workflow.
Disadvantages: traffic spikes and high‑concurrency transactions.
Shopping Cart Payment Scheme
Payment Middleware Heterogeneous Solution
Nginx+LUA Aggregated Front‑End Business Interface Merging
Anti‑Bot Measures
Multi‑Dimensional Personnel Feature Identification
Disclaimer: The materials shared in this public account are collected from the Internet, and all text and images belong to the original authors. They represent personal views only and are provided for learning and exchange purposes. Please verify the content yourself; if any infringement is found, contact the administrator for removal.
IT Architects Alliance
Discussion and exchange on system, internet, large‑scale distributed, high‑availability, and high‑performance architectures, as well as big data, machine learning, AI, and architecture adjustments with internet technologies. Includes real‑world large‑scale architecture case studies. Open to architects who have ideas and enjoy sharing.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.