Problem and Scope
Design a live voting service that can handle high-volume, real-time voting during major events like the Super Bowl. The service should allow viewers to cast votes (e.g., predicting which team will win) and display the results in real-time.
Start by confirming the core user journey, exclusions, success criteria, and the constraints that materially affect the architecture.
Requirements to Clarify
A strong answer should establish scope before choosing components.
Functional requirements:
- Users should be able to vote for one of two options (e.g., which team will win)
- The system should prevent duplicate voting without requiring users to log in
- Aggregated vote results should be displayed in real-time or with minimal delay
- Results should be viewable on both TV screens and potentially on users' devices
Non-functional requirements:
- The system should handle extremely high write traffic (up to 165,000 votes per second at peak)
- Results should be updated with minimal delay (eventual consistency is acceptable)
- The system should be highly available and resilient to component failures
- Vote integrity should be maintained (no duplicate votes from the same user)
- The solution should be cost-effective and scale efficiently
Scale and Capacity
Use the workload to justify storage, partitioning, caching, and reliability decisions. Clarify or challenge these assumptions rather than treating them as unquestionable facts:
- Up to 100 million viewers during a major event like the Super Bowl
- Approximately 10% of viewers might participate in the voting (10 million votes)
- Voting might occur during a 5-minute commercial break (300 seconds)
- Peak voting rate could be 5x the average rate (165,000 votes per second)
- Read traffic depends on display strategy (low for TV-only, high if showing on user devices)
Architecture Discussion
Walk through the important read and write paths, identify ownership boundaries, and explain how the design behaves when dependencies fail. Cover these areas explicitly:
- Frontend interface for users to cast votes
- Backend service(s) to process and store votes
- Data storage solution for votes and aggregation
- System for deduplicating votes
- Result aggregation and calculation mechanism
- Display mechanism for showing results
- Handling extremely high write throughput
- Providing real-time or near-real-time results
- Preventing duplicate votes without user authentication
- Balancing consistency, availability, and partition tolerance
- Scaling efficiently to handle traffic spikes
- Ensuring the system remains responsive under peak load
Follow-up Questions
Expect the interviewer to test the consequences of your choices. Practise answering these questions with a concrete decision, its benefit, and its cost:
- How would your system handle the peak load of 165,000 votes per second?
- Focus: Assess the candidate's answer to "How would your system handle the peak load of 165,000 votes per second" for explicit assumptions, a workable mechanism, failure behavior, and consequential trade-offs.
- What approach would you take to prevent duplicate voting?
- Focus: Assess the candidate's answer to "What approach would you take to prevent duplicate voting" for explicit assumptions, a workable mechanism, failure behavior, and consequential trade-offs.
- How would you balance the trade-off between real-time results and system performance?
- Focus: Assess the candidate's answer to "How would you balance the trade-off between real-time results and system performance" for explicit assumptions, a workable mechanism, failure behavior, and consequential trade-offs.
- What happens if a component in your system fails during the voting period?
- Focus: Assess the candidate's answer to "What happens if a component in your system fails during the voting period" for explicit assumptions, a workable mechanism, failure behavior, and consequential trade-offs.
- How would your approach change if you needed to support millions of users viewing the results in real-time on their devices?
- Focus: Assess the candidate's answer to "How would your approach change if you needed to support millions of users viewing the results in real-time on their devices" for explicit assumptions, a workable mechanism, failure behavior, and consequential trade-offs.
Evaluation Rubric
MockMe evaluates the answer across the following dimensions. A complete answer should connect claims to requirements and explain consequential trade-offs.
- Requirements and scope (15%): Clarifies and prioritizes the required behavior for Users should be able to vote for one of two options (e.g., which team will win); The system should prevent duplicate voting without requiring users to log in; Aggregated vote results should be displayed in real-time or with minimal delay. Establishes the constraints that materially affect Design A Live Polling System, including The system should handle extremely high write traffic (up to 165,000 votes per second at peak); Results should be updated with minimal delay (eventual consistency is acceptable). Strong evidence includes Separates the critical path from secondary features and resolves ambiguous requirements before choosing components.
- Architecture and interfaces (20%): Presents coherent ownership boundaries and end-to-end flows covering Frontend interface for users to cast votes; Backend service(s) to process and store votes; Data storage solution for votes and aggregation; System for deduplicating votes. Strong evidence includes Defines interfaces and traces important success, retry, and failure paths across the proposed components.
- Data and scaling (25%): Uses workload assumptions such as Up to 100 million viewers during a major event like the Super Bowl; Approximately 10% of viewers might participate in the voting (10 million votes) to justify capacity and partitioning decisions. Explains the data, state, or model strategy for Backend service(s) to process and store votes; Data storage solution for votes and aggregation; Balancing consistency, availability, and partition tolerance. Strong evidence includes Quantifies a dominant workload, identifies the first bottleneck, and explains how the design evolves as that workload grows.
- Reliability, correctness, and safety (20%): Explains concrete failure behavior, recovery, and operational safeguards for Balancing consistency, availability, and partition tolerance; Results should be updated with minimal delay (eventual consistency is acceptable); The system should be highly available and resilient to component failures. Strong evidence includes States the required correctness or consistency boundary and covers retries, partial failure, observability, and safe degradation.
- Communication and trade-offs (20%): Drives a structured discussion and compares consequential alternatives for Balancing consistency, availability, and partition tolerance; Scaling efficiently to handle traffic spikes; Ensuring the system remains responsive under peak load. Strong evidence includes Makes assumptions explicit, answers the question asked, and explains both the benefit and cost of major decisions.