Shopping cart and session management in HLD - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Architecture

intermediate

Designing a scalable shopping cart system

You are tasked with designing a shopping cart system that supports millions of users simultaneously. Which architectural choice best ensures scalability and low latency?

A Store shopping cart data in a centralized relational database accessed synchronously for every user action.

B Use client-side cookies to store the entire shopping cart data to avoid server load.

C Implement a distributed in-memory cache (like Redis) to store shopping cart sessions with periodic persistence to a database.

D Save shopping cart data only after checkout to reduce storage needs during browsing.

💡 Hint

Think about fast access and handling many users without bottlenecks.

Using a distributed in-memory cache allows fast read/write access to shopping cart data, reducing latency and supporting high concurrency. Periodic persistence ensures data durability.

🧠 Conceptual

intermediate

Session management strategies for shopping carts

Which session management approach best balances security and user experience for a shopping cart on a web application?

A Store session IDs in secure, HttpOnly cookies with a short expiration time and renew on activity.

B Use URL rewriting to pass session IDs in every link to track user sessions.

C Keep session data entirely on the client side without any server validation.

D Use long-lived sessions without expiration to avoid forcing users to log in repeatedly.

💡 Hint

Consider security risks like session hijacking and user convenience.

Storing session IDs in secure, HttpOnly cookies prevents client-side scripts from accessing them, reducing attack risk. Short expiration with renewal balances security and usability.

❓ scaling

advanced

Handling session data in a load-balanced environment

In a load-balanced web application with multiple servers, what is the best way to manage shopping cart sessions to ensure consistency and availability?

A Keep session data on the client side and send it with every request to avoid server-side session management.

B Store session data only in the database and query it on every request to ensure consistency.

C Use sticky sessions so that each user always connects to the same server storing their session data locally.

D Store session data in a shared distributed cache accessible by all servers to avoid dependency on any single server.

💡 Hint

Consider fault tolerance and server failures in your design.

Using a shared distributed cache allows any server to access session data, improving availability and fault tolerance compared to sticky sessions or database-only storage.

❓ tradeoff

advanced

Tradeoffs in session persistence frequency

What is the main tradeoff when choosing how frequently to persist shopping cart session data from cache to permanent storage?

A Persisting too frequently increases database load but reduces data loss risk; persisting too infrequently reduces load but risks losing recent cart changes.

B Persisting frequently reduces database load but increases network latency; infrequent persistence improves latency but increases storage costs.

C Frequent persistence improves user experience but causes session data fragmentation; infrequent persistence consolidates data but slows checkout.

D Persistence frequency does not affect system performance or data safety significantly.

💡 Hint

Think about balancing system load and data durability.

Persisting session data too often can overload the database, while persisting too rarely risks losing recent user changes if the cache fails.

❓ estimation

expert

Estimating storage requirements for shopping cart sessions

Your e-commerce platform expects 10 million active users daily. Each shopping cart session averages 5 items, with each item record requiring 200 bytes. Sessions are stored in cache for 24 hours. Estimate the approximate memory needed to store all active shopping cart sessions in the cache.

A Approximately 50 GB

B Approximately 100 GB

C Approximately 1 TB

D Approximately 10 GB

💡 Hint

Calculate total bytes: users × items per cart × bytes per item, then convert to GB.

10 million users × 5 items × 200 bytes = 10,000,000 × 1,000 bytes = 10,000,000,000 bytes ≈ 10 GB. But this is raw data; overhead and indexing typically multiply memory needs by about 10, so ~100 GB is realistic.