Question 1

Should shopping cart data be stored in Redis or a database?

Accepted Answer

Hybrid approach is best: Redis for active cart access (fast reads/writes, automatic TTL expiration of abandoned carts), database for durability and cross-device sync. Active cart read/write: HSET cart:{user_id} product:{id} {quantity}; HGETALL cart:{user_id} — sub-millisecond operations. Set TTL (e.g., 30 days of inactivity) for automatic abandoned cart cleanup. Database for persistence: periodically sync Redis cart to the database (on cart update, or when the user navigates away). On login: load cart from database into Redis if Redis key has expired. The database persists carts across Redis restarts and device switches. Anonymous carts: store in Redis keyed by session_id; merge into the authenticated cart on login. Database-only carts: simpler, always consistent, but higher read latency (database query per page load vs. sub-millisecond Redis read).

Question 2

How do you merge an anonymous cart with an authenticated cart on login?

Accepted Answer

When an anonymous user logs in, they may have both an anonymous cart (browsed while not logged in) and a previously saved authenticated cart. Merge algorithm: (1) Load both carts. (2) For each item in the anonymous cart: if the same product+variant exists in the authenticated cart, sum the quantities (cap at inventory_limit if applicable); if not in the authenticated cart, add the item. (3) Discard the anonymous cart after merging. (4) Present the merged cart to the user. Edge cases: item price changed since it was added to the anonymous cart — use the current price (or the cart price policy). Item is now out of stock — show it as unavailable in the merged cart; don't remove silently. The merge must be atomic: read both carts, compute the merged state, write in a single operation to prevent race conditions if the user logs in from two devices simultaneously.

Question 3

How do you validate inventory during checkout without overselling?

Accepted Answer

Inventory validation at checkout must be atomic — two users buying the last item simultaneously must not both succeed. Pattern: (1) Begin a database transaction. (2) SELECT inventory.available_quantity FROM inventory WHERE product_id IN (cart_items) FOR UPDATE — this acquires row locks on inventory records. (3) For each cart item: check that available_quantity >= requested_quantity. If any item fails: return the list of unavailable items to the user; rollback the transaction. (4) If all items are available: decrement available_quantity for each item (UPDATE inventory SET available_quantity = available_quantity - ? WHERE product_id = ? AND available_quantity >= ?). (5) Create the order record. (6) Commit. The FOR UPDATE lock prevents concurrent checkouts from both seeing the same available inventory and both decrementing below zero.

Question 4

Should the shopping cart store prices or compute them dynamically?

Accepted Answer

Two approaches with different trade-offs: (1) Price snapshot: store the price at add-to-cart time (price_snapshot column). The user sees a stable price throughout their shopping session. Honor this price if they return within 24 hours; show a 'price has changed' notice if they return after the snapshot expires. Advantage: user trust (price won't change while they shop), clear pricing before checkout. Disadvantage: prices in the cart may be outdated; requires price-change notification logic. (2) Dynamic pricing: always compute price from the product catalog at display time. User always sees the current price. Advantage: no stale price risk, no price-change management. Disadvantage: price can change between 'add to cart' and 'checkout' — surprising to users if prices increase. At checkout: always validate current price against what the user expects to pay; show a confirmation dialog if prices changed.

Shopping Cart: Low-Level Design

Storage Options

Data Model

Anonymous to Authenticated Cart Merge

Inventory Validation at Checkout

Abandoned Cart Recovery