Problems / Design a product, hard
Design the Amazon storefront from an empty canvas, as in a senior system-design interview: home page, search, product pages, an always-writeable cart, checkout that never oversells or charges twice, and orders that always reach fulfilment, through Prime Day, failures and attacks.
Unlock it once for 25 credits; everything inside it is free (runs, changes, Submit, results, hints). Sign in with Google to start; new accounts get free credits.
Request types to route: home (25%, read), search (30%, read), product (30%, read), cart (10%, write), checkout (2%, write), orders (3%, read). Budget: $65,000 a month.
You start from an empty canvas. When you run the tests, each one simulates your design with its own traffic and failures:
| Test | What it does | Passes when |
|---|---|---|
| Normal day | A normal daily peak in one cell: 2,000 requests a second across home, search, product, cart, checkout and order status, nothing broken. | Success ≥ 99.5%; p99 latency ≤ 100 ms (home); p99 latency ≤ 200 ms (search); p99 latency ≤ 100 ms (product); p99 latency ≤ 100 ms (cart); p99 latency ≤ 2.5 s (checkout); p99 latency ≤ 100 ms (orders) |
| Prime Day: 4× traffic | At 5 s Prime Day deals go live: traffic jumps to 4× the normal peak for 8 s, across every request type. | Success ≥ 99%; Success ≥ 99% (checkout); p99 latency ≤ 300 ms (search); p99 latency ≤ 150 ms (product) |
| The product cache is flushed | At 5 s the product cache is emptied, as after a bad deploy or a cache-cluster failover; it warms up again over about 10 s. | Success ≥ 99%; p99 latency ≤ 150 ms (product); p99 latency ≤ 150 ms (home) |
| The orders database is 8× slower | At 5 s the orders database (the system of record) answers 8× slower for 8 s, as during a long-running migration or a noisy neighbour. | Success ≥ 99% (checkout); p99 latency ≤ 100 ms (orders); p99 latency ≤ 4.0 s (checkout) |
| A server dies | At 4 s one server of the first app service on the request path dies for 10 s. | Success ≥ 99%; p99 latency ≤ 150 ms (product) |
| A DDoS flood, then price scrapers | At 4 s a 20,000 request-a-second flood arrives for 5 s; at 10 s 5,000 requests a second of price scrapers follow for 5 s. Real shoppers keep shopping throughout. | Attack blocked ≥ 90%; Success ≥ 99%; p99 latency ≤ 300 ms (search) |
| The order stream goes down | At 5 s the order event stream (or queue) behind checkout crashes; it comes back after its restart time (10 s unless you set one). | No lost events; Success ≥ 99% (checkout) |
| Redelivered order events on a busy evening | A busy evening at 3× the normal peak for the whole run (about 120 orders a second in this cell, 1,800 in all), and the order stream redelivers some events, as every at-least-once stream does. While this test runs, brokers redeliver unacknowledged messages after 5 s and 0.2% of acknowledgements are lost, as in production: only idempotent consumers avoid duplicates. | No duplicate side effects; Success ≥ 99% (checkout) |
| Budget: $65,000/month | The normal day's design must cost at most $65,000 a month. | Cost ≤ $65,000/month |