Shopping cart and session management in HLD - System Design Guide

Problem Statement

When users add items to their shopping cart, losing that data between page visits or server requests causes frustration and lost sales. If session data is stored only on a single server, users may lose their cart when that server fails or when load balancing routes them to a different server.

Solution

Store session data in a centralized or distributed session store accessible by all servers. Use session IDs stored in user cookies to retrieve the cart state on every request. This ensures the cart persists across multiple requests, servers, and even user devices if designed accordingly.

Architecture

┌───────────────┐       ┌───────────────┐       ┌───────────────┐
│   User Agent  │──────▶│  Web Servers  │──────▶│ Session Store │
│ (Browser/App) │       │ (Multiple)    │       │ (Redis/Memcached) │
└───────────────┘       └───────────────┘       └───────────────┘
        │                      │                      ▲
        │                      │                      │
        │                      └──────────────────────┘
        │                             Retrieve/Store
        └─────────────────────────────────────────────▶
                    Session ID in Cookie

This diagram shows a user interacting with multiple web servers that share session data through a centralized session store. The session ID is stored in the user's cookie and used to fetch the shopping cart state.

Trade-offs

✓ Pros

→

Ensures shopping cart data persists across multiple servers and user requests.

→

Improves fault tolerance by decoupling session data from individual servers.

→

Enables horizontal scaling of web servers without losing session consistency.

→

Supports features like cart recovery and multi-device access if session store is persistent.

✗ Cons

→

Adds latency due to network calls to the session store on each request.

→

Requires additional infrastructure and operational complexity for session store management.

→

Session store can become a bottleneck or single point of failure if not properly scaled.

Use when your application has multiple web servers behind load balancers and needs to maintain user state consistently, especially when user traffic exceeds hundreds of requests per second.

Avoid if your application is a single server with low traffic under 100 requests per second, where in-memory sessions suffice and added complexity is unnecessary.

Real World Examples

Amazon

Uses distributed session management to maintain shopping cart state across multiple servers and devices, ensuring users can add items and return later without losing their cart.

Shopify

Implements centralized session stores to handle millions of concurrent users adding products to carts, enabling seamless scaling and fault tolerance.

Uber

Manages user sessions and state across microservices and servers to provide consistent user experience during ride booking and payment.

Alternatives

Sticky Sessions (Session Affinity)

Routes all requests from the same user to the same server to keep session data in local memory.

Use when: Use when you have a small number of servers and want to avoid external session stores, but can tolerate uneven load distribution.

Token-based Stateless Sessions (JWT)

Stores session data in encrypted tokens on the client side, eliminating server-side session storage.

Use when: Use when you want to scale easily without session stores and can accept trade-offs in token size and security.

Summary

Shopping cart and session management prevent loss of user state across requests and servers.

Centralized session stores enable scalable, fault-tolerant session persistence for multi-server setups.

Alternatives like sticky sessions or token-based sessions have trade-offs in scalability and complexity.