Problems / Real world, hard
Asked at Robinhood and Coinbase. Apps poll quotes from Postgres, place orders through the same API (which calls the exchange and writes positions in the same request), and read portfolios from the same database. At 5 s the market opens and traffic jumps six-fold for 10 seconds.
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.
Success ≥ 99.5%, p99 ≤ 800 ms and Apdex ≥ 0.90 through the open, for at most $16,000 a month.
Like a coding problem, a solution has to pass every case, not just the one it was built for. Submit in the lab runs all 4; 1 of them are hidden until then.
5,000 requests a second for 20 seconds: 80% quote (reads), 15% order (writes), 5% portfolio (reads).
What each component does in this design, and what calls it. The simulator mimics each one from these settings.
| Component | Its job here | Settings |
|---|---|---|
| Load balancerLoad balancer | Traffic enters here.Calls Brokerage API.Layer 4 balancers route by IP and port; layer 7 balancers read HTTP and can route by path or header. | – |
| Brokerage APIApp service | Load balancer forwards to it.Calls Quotes, orders and positions (Postgres), Exchange gateway.Little's law: throughput ≈ concurrency ÷ latency. 200 slots at 50 ms serve about 4,000 req/s. | 12 replicas × 100 slots · timeout 1.0 s |
| Quotes, orders and positions (Postgres)SQL database | Brokerage API calls it.Postgres runs one process per connection, which is why poolers like PgBouncer sit in front of busy databases. | 32 vCPU · 800 connections · 2 read replicas |
| Exchange gatewayMatching engine | Brokerage API calls it for /order.An order book or dispatch queue is processed in sequence per market, which is why one market cannot simply be spread over many CPUs. | 256 slots |