Design interviews / Beginner / 5 min
Design a shopping cart: where it lives, what checkout checks
Browser, cache with a TTL, or database: which carts survive a device switch or a long weekend? Then see why checkout must re-check price and stock.
Start the simulation → Change the load, break a part, watch what happens. Free, no sign-up.
In short
- What it is
- A cart service keeps each shopper’s items between visits, and checkout turns the cart into an order after checking current price and stock.
- Why it matters
- Shoppers switch devices and come back days later, while prices and stock keep changing.
- The trade-off
- A cache is fast but forgets old carts; a database keeps them but costs a little latency; trusting the cart risks wrong prices and overselling.
- Say it in an interview
- "Cart keyed by user id in Redis, written through to a database, guest cart merged on login, and checkout re-validates price and reserves stock before payment."
Check yourself
Why do carts stored only in the browser get lost?
Answer: The shopper comes back on another device, which has its own storage. Local storage lives on one device; a server-side cart tied to the account follows the shopper.
What is the trade-off of keeping carts in Redis with a TTL?
Answer: Fast reads and bounded memory, but carts older than the TTL disappear. Many systems keep hot carts in a cache and persist them to a database so long-lived carts survive.
Why must checkout re-check price and stock?
Answer: The cart may be days old: prices change and items sell out. The cart is a wish list; the order service validates against current price and inventory before charging.