Bird
Raised Fist0
HLDsystem_design~25 mins

Shopping cart and session management in HLD - System Design Exercise

Choose your learning style10 modes available

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
Design: Shopping Cart and Session Management System
Design covers shopping cart operations and session management including storage, retrieval, and expiration. User authentication and payment processing are out of scope.
Functional Requirements
FR1: Allow users to add, update, and remove items in their shopping cart.
FR2: Maintain user session to keep the cart state across multiple requests and visits.
FR3: Support both logged-in users and guest users with temporary sessions.
FR4: Ensure cart data is consistent and available during the shopping process.
FR5: Allow cart recovery after session expiration or user logout.
FR6: Support up to 100,000 concurrent users with low latency.
FR7: Provide APIs for frontend to interact with cart and session data.
Non-Functional Requirements
NFR1: API response time p99 should be under 150ms.
NFR2: System availability should be at least 99.9% uptime.
NFR3: Session data should expire after 30 minutes of inactivity for guests.
NFR4: Persist cart data for logged-in users for at least 30 days.
NFR5: Handle sudden traffic spikes during sales events.
Think Before You Design
Questions to Ask
❓ Question 1
❓ Question 2
❓ Question 3
❓ Question 4
❓ Question 5
❓ Question 6
Key Components
API Gateway or Load Balancer
Session Store (e.g., Redis)
Cart Data Store (e.g., NoSQL or Relational DB)
Authentication Service
Cache Layer
Background Jobs for session expiration and cart cleanup
Design Patterns
Session Token Management (Cookies or JWT)
Cache Aside Pattern for cart data
Eventual Consistency for cart updates
Sticky Sessions vs Stateless Sessions
Data Expiration and TTL management
Reference Architecture
Client
  |
  v
API Gateway / Load Balancer
  |
  v
+---------------------+       +------------------+
| Session Store (Redis)|<----->| Authentication   |
+---------------------+       | Service          |
          |                   +------------------+
          v
+---------------------+
| Cart Service        |
| (Business Logic)    |
+---------------------+
          |
          v
+---------------------+
| Cart Data Store     |
| (NoSQL DB)          |
+---------------------+

Background Jobs
  |
  v
Session Expiration & Cart Cleanup
Components
API Gateway / Load Balancer
Nginx / AWS ALB
Route client requests to appropriate services and handle SSL termination.
Session Store
Redis
Store session tokens and temporary session data with TTL for fast access.
Authentication Service
OAuth2 / JWT Provider
Authenticate users and issue session tokens.
Cart Service
Node.js / Java Spring Boot
Handle cart operations like add, update, remove items and session validation.
Cart Data Store
MongoDB / DynamoDB
Persist cart data for logged-in users and support fast read/write.
Background Jobs
Cron Jobs / AWS Lambda
Clean expired sessions and carts, maintain data hygiene.
Request Flow
1. 1. Client sends request to API Gateway with session token (cookie or header).
2. 2. API Gateway forwards request to Cart Service.
3. 3. Cart Service validates session token with Session Store.
4. 4. If session valid, Cart Service fetches cart data from Cart Data Store or cache.
5. 5. Client performs cart operations (add/update/remove).
6. 6. Cart Service updates cart data in Cart Data Store and optionally cache.
7. 7. Session Store updates session TTL to keep session alive.
8. 8. Background Jobs periodically remove expired sessions and carts.
Database Schema
Entities: - User: user_id (PK), email, password_hash, created_at - Session: session_id (PK), user_id (FK nullable), cart_id (FK nullable), session_token, last_active, expires_at - Cart: cart_id (PK), user_id (FK nullable), created_at, updated_at - CartItem: cart_item_id (PK), cart_id (FK), product_id, quantity Relationships: - One User can have multiple Sessions. - One User can have one active Cart. - One Cart has many CartItems. - Guest users have sessions without user_id but with cart_id.
Scaling Discussion
Bottlenecks
Session Store overload due to high read/write traffic.
Cart Data Store slowdowns with large number of concurrent writes.
API Gateway becoming a single point of failure or bottleneck.
Background jobs causing spikes in database load during cleanup.
Solutions
Use Redis clustering and partitioning to scale Session Store horizontally.
Choose a scalable NoSQL database with auto-sharding for Cart Data Store.
Deploy multiple API Gateway instances behind a load balancer for high availability.
Schedule background jobs during off-peak hours and throttle cleanup tasks.
Interview Tips
Time: Spend 10 minutes understanding requirements and clarifying scope, 20 minutes designing components and data flow, 10 minutes discussing scaling and trade-offs, 5 minutes summarizing.
Explain how session management supports both guest and logged-in users.
Discuss trade-offs between storing cart data in session store vs persistent DB.
Highlight importance of TTL and expiration for session cleanup.
Describe how caching improves read performance for cart data.
Address scaling challenges and solutions for high concurrency.
Mention security considerations like token validation and data privacy.

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