Voting System

September 18, 2022 6:00 PM PDT

---

This document summarizes the discussion held during a mock system design interview focused on a voting system for a talent show. The interview covered functional and scaling requirements, system design considerations, and various technical challenges related to handling a large number of users and votes.

Requirements

Functional Requirements

• Users can vote for a talent show.
• Voting period lasts for 24 hours.
• Users can query voting results anytime before or after the voting period.
• Voting is accessible via phone, web, and mobile.
• Only registered users can vote.
• VIP users can cast 10 votes for up to three contestants.
• Regular users can cast 1 vote for up to three contestants.
• Data retention for voting results is set to 1 month.

Scaling Requirements

• Target user base: 1 billion voters.
• VIP users: 1,000.
• System must support low latency, high availability, and high consistency.
• Scalability to handle up to 1 billion users.

Estimations

• Queries per second (QPS): 10,000 (calculated as 1 billion votes divided by 100,000).
• Storage requirement: Approximately 1 TB for user data.

System Design

Database Schema

• User: (name, email, dob, phone, isVIP, creation_date)
• Score: (contestantId, voteCount)
• Voter: (contestantId, voteCount)

APIs

• POST /api/v1/vote

  • Request: (api_key, contestantId, voteCount)
  • Response: 200 OK

• GET /api/v1/score

  • Request: (api_key, size, sortorder)
  • Response: List of contestants meeting the criteria in JSON format.

Handling Fraud

• Use voter ID to track votes.
• Implement security measures such as two-factor authentication (2FA).
• Validate timestamps to ensure votes are cast within the allowed period.

Technical Considerations

• Throughput Management:

  • If one machine can handle 1,000 requests per second, then 10 machines are required to meet the throughput of 10,000 requests per second.
  • Utilize multiple web servers and voting servers, with Redis for handling reads.

• Data Aggregation:

  • Consider using a Lua script for transactions, but be aware of potential performance issues.
  • Discussed the use of message queues (MQ) and Spark for data aggregation.

• Handling Overvotes and Missing Votes:

  • Frontend should manage these scenarios.
  • IP address filtering can help mitigate fake votes.

• Redis Usage:

  • Redis can persist data through snapshots and append-only files.
  • Each shard can maintain its own counter for votes, and aggregation can occur at the application server level.

Additional Feedback

• Interviewer and audience provided feedback on the design, suggesting improvements in areas such as load testing, handling hot partitions, and ensuring that each user can only vote a limited number of times.
• Discussed the potential need for auto-scaling solutions and the implications of using cloud services for deployment.

Conclusion

The mock interview highlighted the complexities involved in designing a scalable and secure voting system. The discussion covered various technical aspects, including database design, API specifications, and strategies for managing high throughput and potential fraud. Further research and refinement of the design are recommended to address identified challenges and improve overall system performance.