Designing Scalable Shopping Cart Storage: Principles and Choices

1. Core Functions

Add product to cart ("add to cart")

Cart list page

Initiate checkout

Cart icon displayed on all pages

2. Essential Attributes

Each cart item must store the product ID (SKUID), quantity, timestamp of addition, and a "selected" flag indicating whether the item is included in the checkout.

3. Design Principles

3.1 User State Considerations

If the user is not logged in, the cart must be persisted locally so that closing the browser does not lose the items.

When the user logs in later, the locally stored items are merged into the user’s permanent cart.

Closing the browser clears the temporary cart, but the merged permanent cart remains.

Using the same account on another device (e.g., mobile) shows the same cart contents.

3.2 Storage Rules

Store a temporary cart for unauthenticated users.

When a user logs in, merge the temporary cart into the permanent cart and delete the temporary one.

Synchronize the permanent cart across browsers, mobile apps, and other clients.

4. Temporary Cart Storage Design

4.1 Client‑Side vs Server‑Side

Storing the temporary cart on the server would require a globally unique identifier for each cart and waste server resources, so the preferred approach is client‑side storage.

4.2 Client‑Side Options

Session (not suitable because it is short‑lived and stored on the server).

Cookie – automatically sent with each request, easy for the server to read/write.

LocalStorage – larger capacity (no 4 KB limit) but only accessible from the client.

Choosing between Cookie and LocalStorage depends on the scenario: Cookie offers simpler server‑side handling, while LocalStorage provides more space and avoids sending data on every request.

5. Permanent User Cart Storage Design

5.1 MySQL Table

A relational table (e.g., cart) stores each item as a row with columns for user_id, sku_id, count, timestamp, and selected. An index on user_id speeds up lookups.

{
  "cart": [
    {"SKUID": 8888, "timestamp": 1578721136, "count": 1, "selected": true},
    {"SKUID": 6666, "timestamp": 1578721138, "count": 2, "selected": false}
  ]
}

5.2 Redis Hash

Redis can store the cart as a hash where the key is the user_id and each field is a sku_id. The field value is a JSON string containing the timestamp, count, and selected flag.

{
  "KEY": 6666,
  "VALUE": [
    {"FIELD": 8888, "FIELD_VALUE": {"timestamp": 1578721136, "count": 1, "selected": true}},
    {"FIELD": 6666, "FIELD_VALUE": {"timestamp": 1578721138, "count": 2, "selected": false}}
  ]
}

5.3 MySQL vs Redis

Redis offers higher read/write performance and lower latency, suitable for high‑concurrency scenarios.

MySQL provides stronger durability and richer query capabilities (joins, transactions), which can be useful for analytics or complex queries.

For a typical shopping cart, occasional data loss is acceptable, so Redis’s weaker durability may be tolerable.

In practice, many systems start with MySQL for simplicity and later add Redis as a cache if performance becomes a bottleneck.

6. Summary

The cart system’s main functions are add‑to‑cart, cart listing, and checkout.

Only one core entity – the cart – is needed, with attributes SKUID, quantity, timestamp, and selected flag.

Two storage layers are required: a client‑side temporary cart (Cookie or LocalStorage) and a server‑side permanent cart (MySQL or Redis).

Temporary carts are merged into the permanent cart upon login and cleared thereafter.

Choosing MySQL gives reliability and flexibility; Redis gives speed. The final choice depends on expected traffic, data‑consistency requirements, and system complexity.

7. Further Thought

Using Redis as a cache in front of MySQL is technically feasible, but the cache‑hit rate for individual carts is often low, and maintaining cache consistency adds complexity. Only large‑scale systems typically justify this extra layer.