Design a Massive Live Two-Choice Voting System

# Design a Massive Live Two-Choice Voting System Design a voting system for a major live event. The host presents one question with choices A and B. A user may cast at most one vote. After voting, the user should immediately see a near-real-time result. When the event closes, the host must receive an accurate final count. The traffic is highly bursty and may reach a nationwide audience within a few minutes. ### Clarifying Questions to Ask - What identifies a unique eligible user, and may a submitted vote be changed? - Does “immediately” require read-your-write behavior, and how stale may the global percentage be? - Is the live result allowed to be approximate while voting remains open? - What audit, anti-abuse, regional, and disaster-recovery requirements apply? - Who is authorized to open, close, and finalize the vote? ### What a Strong Answer Covers - Vote event, voter identity, immutable vote, idempotency, and lifecycle state models. - A burst-tolerant write path that durably accepts one vote per user. - Fast regional or sharded counters for live display, with honest freshness semantics. - An authoritative deduplicated store and a finalization process that produces accurate A and B counts. - Hot-key avoidance, backpressure, retries, late events, abuse controls, auditability, and regional failure handling. ### Follow-up Questions 1. How can a user see their own vote reflected immediately when the global counter is delayed? 2. How do you prove the final count is complete after duplicate deliveries and regional retries? 3. What happens to votes accepted near the exact close time? 4. How would you limit automated voting without excluding legitimate users behind shared networks?