Problems / Real world, hard
Asked at Dropbox and Google (Drive). Uploads and downloads of 4 MB chunks are proxied through the file API, which spends 25 ms of CPU and up to 600 ms per chunk; metadata reads hit Postgres. At 9 s a team shares a large folder and traffic doubles.
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 ≤ 6 s and Apdex ≥ 0.90, 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.
4,000 requests a second for 20 seconds: 25% upload (writes), 45% download (reads), 30% meta (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 File API (proxies every chunk).Layer 4 balancers route by IP and port; layer 7 balancers read HTTP and can route by path or header. | – |
| File API (proxies every chunk)App service | Load balancer forwards to it.Calls Block storage (4 MB chunks), File metadata (Postgres).Little's law: throughput ≈ concurrency ÷ latency. 200 slots at 50 ms serve about 4,000 req/s. | 12 replicas × 100 slots · timeout 14 s |
| Block storage (4 MB chunks)Object storage | File API (proxies every chunk) calls it for /upload, /download.Object stores like S3 keep copies across devices and facilities for very high durability. | 5000 slots · 300,000 calls/min |
| File metadata (Postgres)SQL database | File API (proxies every chunk) calls it.Postgres runs one process per connection, which is why poolers like PgBouncer sit in front of busy databases. | 8 vCPU · 400 connections |