Design an Online Polling Service
Design a service for creating and collecting real-time poll results at massive scale. Focus on read-heavy vs. write-heavy phases and database choice (SQL vs. Redis).
Why Interviewers Ask This
Interviewers at Meta ask this to evaluate your ability to handle extreme scale and read-heavy workloads typical of their social products. They specifically test your capacity to distinguish between transient write phases during poll creation and sustained read phases for result aggregation, ensuring you can justify database choices like Redis for caching versus SQL for durability under massive concurrent traffic.
How to Answer This Question
1. Clarify requirements immediately: Ask about expected daily active users, peak QPS, and whether results need real-time accuracy or eventual consistency. 2. Define the core components: Outline a client app, load balancer, API gateway, and distinct services for poll creation and voting. 3. Address the read/write asymmetry: Propose using Redis as a high-speed cache for vote counts during the active polling phase to handle millions of reads per second, while deferring writes to a durable SQL database like Cassandra or MySQL only after batching. 4. Design the data model: Explain how to store poll metadata in SQL but aggregate votes in Redis using hash structures with atomic increment operations. 5. Discuss scaling strategies: Mention sharding based on poll ID, rate limiting to prevent abuse, and using a CDN for static assets. Conclude by summarizing how this architecture balances latency with data integrity.
Key Points to Cover
- Explicitly identifying the read-heavy nature of polling systems after the initial creation phase
- Justifying Redis over SQL for vote counting due to atomic operations and low latency
- Proposing an asynchronous batch-write strategy to offload pressure from the primary database
- Addressing concurrency control through atomic increments to prevent lost updates
- Considering sharding strategies to distribute load across multiple nodes for massive scale
Sample Answer
To design a scalable online polling service for Meta's audience, I would first clarify that we expect millions of concurrent users during viral events, creating a classic read-heavy workload once polls are live. The syst…
Common Mistakes to Avoid
- Treating all database interactions equally without distinguishing between metadata storage and high-frequency vote counting
- Ignoring the potential for race conditions when multiple users vote simultaneously without atomic operations
- Failing to mention caching strategies, leading to a bottleneck on the primary database during peak traffic
- Overlooking the need for eventual consistency models which are acceptable for non-critical real-time stats
Sound confident on this question in 5 minutes
Answer once and get a 30-second AI critique of your structure, content, and delivery. First attempt is free — no signup needed.