How the interviewer opens it
“Design a persistent shopping cart for an online store. Shoppers can shop as guests or sign in from different devices.”
The prompt is vague on purpose. The first minutes are for you. Reduce the prompt to the core features and agree on the numbers before you draw.
What to clarify first
- Scale and traffic
- Cart size and lifetime
- Guest and account identity
- Cart edits
- Merge rules
- Product changes
- Latency
- Correctness and durability
- Deployment and dependencies
- Scope limits
The interviewer has the answers. In a SysRound round, Alex gives these answers, as a real interviewer does.
Scope of a strong answer
Core requirements
- Keep guest carts and account carts across visits
- Apply concurrent cart edits without silent data loss
- Merge a guest cart into an account cart once
- Show product prices and availability without inventory reservations
Usually out of scope
- Checkout and payment
- Inventory reservations
- Coupons and tax calculation
- Implementation of the identity and catalog services
What interviewers ask about
- Concurrent cart edits
- Two devices can act on the same old cart. The service must distinguish additions from replacements to avoid silent data loss.
- Lost responses and repeated requests
- An addition can commit even when the client receives no response. A later retry must not repeat that addition.
- Guest carts at sign-in
- A merge changes two carts while devices can still edit both. The service must apply quantity caps without repeated contributions or partial results.
- Product changes
- A durable cart does not guarantee a price or stock. The catalog can fail while the cart remains available.
Common mistakes
- The design stores the only cart copy in the browser or a cache.
- The server replaces the whole cart without a version check.
- A retry adds an item twice or repeats a guest merge.
- The merge overwrites the account cart, loses an edit, or applies the wrong quantity cap.
- The cart reserves stock or promises a price that checkout cannot honor.
- The server changes millions of carts when one product becomes unavailable.
The bar by level
- Mid-level (L4/E4)
- The candidate defines guest and account ownership, a durable data model, and clear cart APIs. The candidate prevents lost edits and applies the stated merge limits.
- Senior (L5/E5)
- The candidate makes edits and merges atomic and safe to retry. The candidate resolves merge races, defines conflict responses, and handles catalog failures.
- Staff (L6+/E6+)
- The candidate traces failures across guest edits, account edits, and retries. The candidate protects account access after a merge. The candidate justifies region failover limits, conflict boundaries, and catalog costs with numbers.