Bird
Raised Fist0
HLDsystem_design~7 mins

Shopping cart and session management in HLD - System Design Guide

Choose your learning style10 modes available
LearnWhyDeepArchPracticeChallengeDesignRecallScale

Start learning this pattern below

Jump into concepts and practice - no test required

or
Recommended
Test this pattern10 questions across easy, medium, and hard to know if this pattern is strong
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.

Practice

(1/5)
1. What is the primary purpose of session management in a shopping cart system?
easy
A. To keep track of user activity and cart contents securely
B. To permanently store all user purchases in the database
C. To display advertisements based on user preferences
D. To manage payment processing and billing

Solution

  1. Step 1: Understand session management role

    Sessions keep temporary data about a user's interaction, such as cart contents and login status.

  2. Step 2: Identify the main goal in shopping cart context

    The main goal is to track user activity and cart items securely during their visit.

  3. Final Answer:

    To keep track of user activity and cart contents securely -> Option A

  4. Quick Check:

    Session = Track user and cart data [OK]
Hint: Sessions track temporary user data like cart items [OK]
Common Mistakes:
  • Confusing session with permanent storage
  • Thinking sessions handle payment processing
  • Assuming sessions display ads
2. Which of the following is the correct way to maintain a user's shopping cart session in a web application?
easy
A. Store cart data only in browser cookies without server validation
B. Require user to log in before adding items to cart
C. Save cart data directly in the URL query parameters
D. Use a unique session ID stored in a cookie linked to server-side cart data

Solution

  1. Step 1: Review session management best practice

    Best practice is to store a unique session ID in a cookie that references server-side data.

  2. Step 2: Evaluate options for security and scalability

    Storing cart data only in cookies or URLs is insecure and limited in size; requiring login is not always needed.

  3. Final Answer:

    Use a unique session ID stored in a cookie linked to server-side cart data -> Option D

  4. Quick Check:

    Session ID cookie + server data = Correct [OK]
Hint: Session ID cookie links to server cart data securely [OK]
Common Mistakes:
  • Storing sensitive data only in cookies
  • Putting cart info in URL causing security risks
  • Assuming login is mandatory for cart usage
3. Consider this simplified flow for a shopping cart session: 
1. User adds item A to cart
2. Server stores cart in session store
3. User adds item B
4. Server updates session
5. User refreshes page
6. Server retrieves session cart
What will the cart contain after step 6?
medium
A. Only item B
B. Only item A
C. Both item A and item B
D. Empty cart

Solution

  1. Step 1: Track items added to cart in session

    Item A is added first and stored in session, then item B is added and session updated.

  2. Step 2: Understand session retrieval on refresh

    On refresh, server retrieves the session cart which includes both items added previously.

  3. Final Answer:

    Both item A and item B -> Option C

  4. Quick Check:

    Session stores cumulative cart items [OK]
Hint: Session updates accumulate cart items, not replace [OK]
Common Mistakes:
  • Assuming new item replaces old in session
  • Thinking refresh clears session data
  • Confusing client-side and server-side storage
4. A developer notices that users lose their shopping cart items after closing the browser. What is the most likely cause?
medium
A. Cart data is stored permanently in the database
B. Session cookie is set as a session-only cookie without expiration
C. User authentication is required to save cart
D. Server is caching cart data incorrectly

Solution

  1. Step 1: Understand session cookie behavior

    Session cookies without expiration are deleted when browser closes, losing session data.

  2. Step 2: Identify cause of cart loss

    Because cart data is linked to session cookie, losing cookie means losing cart info.

  3. Final Answer:

    Session cookie is set as a session-only cookie without expiration -> Option B

  4. Quick Check:

    Session cookie expires on browser close [OK]
Hint: Session cookies without expiry vanish on browser close [OK]
Common Mistakes:
  • Assuming database storage causes cart loss
  • Thinking authentication affects session persistence
  • Blaming server cache without evidence
5. You are designing a scalable shopping cart system for millions of users. Which approach best balances performance and reliability for session and cart management?
hard
A. Use a distributed in-memory session store with periodic database backups
B. Store cart data in client-side cookies only to reduce server load
C. Save all cart data directly in the main database synchronously on every change
D. Require users to log in before adding items to cart to simplify session handling

Solution

  1. Step 1: Evaluate client-side vs server-side storage

    Client-only storage risks security and size limits; main DB sync on every change causes latency.

  2. Step 2: Consider scalability and reliability

    Distributed in-memory store (like Redis) offers fast access and can be backed up to DB for durability.

  3. Step 3: Assess login requirement impact

    Requiring login reduces friction and scalability; anonymous carts improve UX.

  4. Final Answer:

    Use a distributed in-memory session store with periodic database backups -> Option A

  5. Quick Check:

    Distributed cache + DB backup = Scalable & reliable [OK]
Hint: Use distributed cache with DB backup for scalable sessions [OK]
Common Mistakes:
  • Relying only on client cookies for cart data
  • Writing to DB synchronously on every cart update
  • Forcing login before cart usage unnecessarily