Design a checkout flow
hardComplete guide with examples and interview questions · 45 min
Say it out loud in an interview — clear, simple, no textbook wording.
If someone asks me to design a checkout flow, I would say it is a state machine where money changes hands, and every transition must be safe to retry. The steps are familiar: cart, shipping, payment, review, confirmation. The design problem is what happens between them when networks fail, users refresh, and cards decline.
Interviewers care because checkout is where frontend shortcuts become real losses. A client-confirmed order, a client-computed total, or a retry without an idempotency key each fail in ways that cost money or trust. The question tests whether you treat payment as a correctness problem, not a form problem.
The senior nuance is pessimism in the right places. The client is optimistic about display and pessimistic about money: it shows estimates instantly, but it never confirms an order, never trusts its own totals, and never assumes a payment result it has not heard from the server.
Key takeaways
- •Checkout is a state machine, not a form: every step has a valid next state and a defined failure state
- •Money rules out optimism: the order is confirmed only when the server confirms payment, never before
- •Prices are computed server-side; the client shows estimates, never totals the server trusts
- •Idempotency keys make retry safe: the same key, the same outcome, never a second charge
- •Abandoned checkouts are normal, so drafts persist and resume instead of vanishing
Track your mastery
Sign in to save Q&A scores, coding challenge progress, points, and streaks across devices.
Sign in to save progress