Coding - Web API for Article Voting System

In a Netflix backend or system design interview, the Article Voting System (often framed as a "Design Reddit" or "Live Voting Service" problem) tests your ability to handle high-concurrency writes, data consistency, and real-time aggregation at scale. YouTube +1 0 1

Problem Statement Summary

You are tasked with designing a web API and backend for a system where millions of users can upvote or downvote articles (or videos/posts). The primary challenge is managing a massive volume of concurrent write operations (e.g., during a live event like the Super Bowl) while providing near real-time vote counts to all viewers. YouTube +2 0 1

Functional Requirements

• Vote Casting: Users can upvote, downvote, or retract their vote on a specific article.
• Vote Counting: The system must maintain an accurate, aggregated count of votes for each article.
• Uniqueness: Prevent duplicate voting from the same user on the same article.
• Ranked Feed: (Optional) Retrieve articles sorted by "Top," "New," or "Hot" (trending). YouTube +2

Non-Functional Requirements

• High Availability: The system must remain operational even during massive traffic spikes.
• Scalability: Must handle millions of users and high throughput (e.g., 100k+ transactions per second).
• Low Latency: Voting and viewing updated counts should feel instantaneous to the user.
• Eventual Consistency: While the total count must be accurate eventually, slight delays in reflecting a single vote globally are often acceptable in exchange for higher availability. YouTube +3

Proposed Web API Design

Netflix interviewers often look for clean, RESTful endpoints that address idempotency and security: Medium +1 3

Action | Endpoint | Method | Key Parameters --- | --- | --- | --- Cast/Change Vote | /v1/articles/{article_id}/vote | POST | user_id, vote_type (UP/DOWN/NONE) Get Vote Count | /v1/articles/{article_id}/stats | GET | article_id Get Article Feed | /v1/feed/{category} | GET | category (top, hot), limit, offset

Interview Deep-Dive Topics

• Write Heavy vs. Read Heavy: Discuss how to handle 100k+ TPS by using a write-behind cache (like Redis) or a message queue (like Apache Kafka) to buffer votes before updating the main database.
• Idempotency: How to ensure a network retry doesn't count the same vote twice (e.g., using a unique request_id or a composite primary key of user_id + article_id).
• Aggregation Strategies: Should you calculate the total count on the fly (slow) or maintain a pre-aggregated counter (fast but requires concurrency handling like Distributed Locks)? YouTube +3

Would you like to explore the database schema or the specific concurrency control strategies used to prevent race conditions during vote counting?

[0] - System Design: Real-time Superbowl Voting (with FAANG ... [1] - System design interview question from Netflix - Design a web ... [2] - System Design Interview: Design Netflix [3] - System Design — Netflix. A real product architecture interview… [4] - Netflix's Counter Abstraction: A Hidden Gem for System Design ... [5] - 80% of the System Design interviews I've given in the last 7 ... [6] - Design a Voting System [7] - System Design Interview: Netflix | A Deep Dive into Scalable ... [8] - Meta Interview Question: Design a Voting System - Final Round AI