Polling System
Create polls, cast votes, tally results.
Back-of-the-envelope
Show assumptions
- 10M DAU, 5 poll views/user/day = 50M poll views/day
- 1% of viewers vote = 500K votes/day = 5.8 votes/sec average, 100/sec peak
- 1M active polls at any time
- Real-time results display; tally within 1s of vote
Level-by-level design for Polling System
Pick your interview level (L4/L5/L6/L7). See what the interviewer expects at that level, then walk through the design at every scale (10K → 1B RPS) with the depth expected for that level. Applies the same universal rubric across all system designs.
All 4 interview levels at a glance
Click any level to focus below — or scroll to see all four side-by-side.
What L4 interviewer expects
Can you produce a working, boring, correct architecture that ships in 6-8 weeks with a small team? Do you know when NOT to add complexity?
- Functional requirements (2-4 sentences)
- One clarifying question that reveals a real trade-off
- Back-of-envelope estimation (DAU × requests/user = RPS)
- 3-5 API endpoints with correct HTTP verbs
- Data model with primary key + at least one index reasoning
- 3-tier architecture: LB + stateless app servers + database
- Multi-AZ database for basic HA
- Rough cost floor ('runs at $X/mo')
- Microservices at 10K RPS (over-engineering)
- Kafka / Kinesis without a clear stream use case
- Sharding before you've saturated one primary
- Multi-region for an MVP with no international users
- Kubernetes for 3 engineers
- No API design → 'never shipped a real service'
- No cost floor → 'never owned a budget'
- Adds Redis + Kafka + microservices → 'copies best practices without thinking'
- Cannot explain a single failure mode → 'never been on-call'
A great L4 answer explicitly REJECTS complexity and defends the boring choice. 'I'm NOT adding Redis because at 10K RPS with 100:1 R:W my Postgres handles this at 30% CPU. Adding Redis introduces invalidation problems for zero benefit at this scale.' That's the L4-borderline-L5 signal.
Design at every scale — with L4 depth
At L4, an interviewer might probe you at any scale (10K → 1B RPS). Here's the depth of answer expected at each — for Polling System specifically.
L4 lives here — go deep
3-engineer startup, $500/mo infra budget, 8-week deadline
Walk through: requirements → estimation → API → data model → boring 3-tier. Explicitly REJECT premature complexity. Show restraint.
Adding Redis/Kafka/microservices because 'best practice.' Interviewer reads this as junior-thinking.
Confident sketch
10-30 engineer team, $2K-5K/mo infra, first paying enterprise customer
Name the bottleneck (usually DB read CPU). Pick exactly the right mitigation (cache-aside + read replicas). Explicitly reject premature sharding.
Jumping to sharding at 100K. Or listing 5 options without picking one.
One sentence — no depth-faking
40-100 engineers, $20K/mo infra, multi-region, cross-team coordination
'At 1M I'd introduce sharding, multi-region with CDN, and eventual-consistency IDs. But 1M is L5+ territory, so I'll defer unless you want depth.'
Bluffing depth you don't have. Interviewer detects it in 30 seconds.
Acknowledge & defer
200+ engineers, $50M+/yr infra, capital allocation, regulator conversations
'1B is platform-scale — business + org problem, not primarily technical. That's L7 conversation. Won't fake depth.'
Making up numbers or claiming familiarity you don't have.