Problems / Design a product, hard
Design a Stripe-like payments API from an empty canvas: idempotent charges and refunds on a ledger, card networks that fail, and webhooks that always arrive exactly once in effect.
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: charge (20%, write), refund (5%, write), status (75%, read). Budget: $320,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 | The normal day: the traffic in the brief, nothing broken. 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. | Success ≥ 99% (charge); Success ≥ 99% (refund); p99 latency ≤ 2.5 s (charge); p99 latency ≤ 100 ms (status); No duplicate side effects |
| The webhook queue goes down | At 5 s the first event stream or queue on the request path crashes; it comes back after its restart time (10 s unless you set one). | No lost events; Success ≥ 99% (charge) |
| Credential stuffing | At 5 s 3,000 requests a second of credential stuffing traffic arrive for 10 s, alongside real users. | Attack blocked ≥ 85%; Success ≥ 99% (charge) |
| A server dies | At 4 s one server of the first app service on the request path dies for 10 s. | Success ≥ 99% (charge); Success ≥ 99% |
| Budget: $320,000/month | The normal day's design must cost at most $320,000 a month. | Cost ≤ $320,000/month |