Backend Development 6 min read

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.

IT Architects Alliance
IT Architects Alliance
IT Architects Alliance
Design and Architecture of a Cloud Shopping Cart System

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.

backenddistributed systemssystem architecturecachingpaymentshopping-cartelasticity
IT Architects Alliance
Written by

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.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.