Practice/Meta/Design an Instagram Story Viewer

Design an Instagram Story Viewer

Mobile System DesignMust

Problem Statement

You need to design a real-time polling system that allows event organizers to create and launch interactive polls during large virtual conferences, webinars, and town halls. Attendees should be able to vote from their mobile devices or web browsers, see results update in real-time, and view aggregate statistics as votes come in. The system must handle events with up to 100,000 concurrent participants, where a significant portion of the audience may vote within the first 10-30 seconds of a poll being launched.

The platform should support multiple question types (multiple choice, yes/no, rating scales), allow moderators to control poll timing and visibility, and provide analytics on participation rates and response patterns. Consider that network conditions vary widely across a global audience, and some users may experience temporary disconnections during voting.

Key Requirements

Functional

Poll creation and management -- organizers can create polls with various question types, schedule or launch them instantly, and close voting at will
Real-time voting -- attendees cast votes that are immediately recorded and reflected in live result displays
Result visualization -- both organizers and attendees see updating bar charts, percentages, and vote counts as responses arrive
Historical analytics -- post-event access to voting patterns, participation metrics, and demographic breakdowns
Duplicate vote prevention -- ensure each attendee can only vote once per poll while maintaining voter anonymity

Non-Functional

Scalability -- support 100,000 concurrent voters with burst traffic of 50,000 votes in the first 30 seconds
Reliability -- maintain 99.9% uptime during scheduled events with graceful degradation if components fail
Latency -- vote submission acknowledged within 200ms, result updates propagated to viewers within 2 seconds
Consistency -- eventual consistency acceptable for vote counts, but no vote should be lost or double-counted

What Interviewers Focus On

Based on real interview experiences, these are the areas interviewers probe most deeply:

1. Handling Vote Ingestion at Scale

The system must handle extreme spikes in traffic when a poll opens, as most participants tend to vote immediately. Interviewers want to see how you handle this burst pattern without dropping votes or overwhelming your infrastructure.

Hints to consider:

Message queues can buffer incoming votes during traffic spikes and smooth out processing
Write-heavy workloads may benefit from different database patterns than read-heavy ones
Consider whether votes need strong consistency or if eventual consistency is acceptable
Rate limiting per user vs. global capacity management tradeoffs

2. Real-Time Result Distribution

Broadcasting updated results to tens of thousands of concurrent viewers creates significant fanout challenges. Interviewers look for understanding of push vs. pull architectures and how to minimize server load.

Hints to consider:

WebSocket connections consume server resources; consider connection pooling or alternative protocols
Not every vote needs to trigger an update to every client immediately
Client-side aggregation and batching can reduce server-to-client message volume
CDN and edge caching strategies for distributing static poll metadata

3. Vote Deduplication and Identity

Preventing duplicate votes while preserving voter anonymity requires careful design. Interviewers want to see you balance security, privacy, and operational complexity.

Hints to consider:

Session tokens vs. device fingerprinting vs. account-based identity
Idempotency keys ensure network retries don't create duplicate votes
Time-based tokens can automatically expire after poll closes
Trade-offs between strong authentication and participation friction

4. Database Schema and Query Patterns

The data access patterns for polls involve both rapid writes during voting and frequent reads for result aggregation. Interviewers assess whether your schema design supports both efficiently.

Hints to consider:

Separating vote storage from aggregate counts can optimize for different access patterns
Precomputed aggregates vs. on-demand calculation trade-offs
Partitioning strategies for isolating different polls or events
Time-series databases may be appropriate for vote timestamp analytics

Practice/Meta/Design an Instagram Story Viewer

Design an Instagram Story Viewer

Mobile System DesignMust

Problem Statement

Key Requirements

Functional

Poll creation and management -- organizers can create polls with various question types, schedule or launch them instantly, and close voting at will
Real-time voting -- attendees cast votes that are immediately recorded and reflected in live result displays
Result visualization -- both organizers and attendees see updating bar charts, percentages, and vote counts as responses arrive
Historical analytics -- post-event access to voting patterns, participation metrics, and demographic breakdowns
Duplicate vote prevention -- ensure each attendee can only vote once per poll while maintaining voter anonymity

Non-Functional

Scalability -- support 100,000 concurrent voters with burst traffic of 50,000 votes in the first 30 seconds
Reliability -- maintain 99.9% uptime during scheduled events with graceful degradation if components fail
Latency -- vote submission acknowledged within 200ms, result updates propagated to viewers within 2 seconds
Consistency -- eventual consistency acceptable for vote counts, but no vote should be lost or double-counted

What Interviewers Focus On

Based on real interview experiences, these are the areas interviewers probe most deeply:

1. Handling Vote Ingestion at Scale

Hints to consider:

Message queues can buffer incoming votes during traffic spikes and smooth out processing
Write-heavy workloads may benefit from different database patterns than read-heavy ones
Consider whether votes need strong consistency or if eventual consistency is acceptable
Rate limiting per user vs. global capacity management tradeoffs

2. Real-Time Result Distribution

Hints to consider:

WebSocket connections consume server resources; consider connection pooling or alternative protocols
Not every vote needs to trigger an update to every client immediately
Client-side aggregation and batching can reduce server-to-client message volume
CDN and edge caching strategies for distributing static poll metadata

3. Vote Deduplication and Identity

Preventing duplicate votes while preserving voter anonymity requires careful design. Interviewers want to see you balance security, privacy, and operational complexity.

Hints to consider:

Session tokens vs. device fingerprinting vs. account-based identity
Idempotency keys ensure network retries don't create duplicate votes
Time-based tokens can automatically expire after poll closes
Trade-offs between strong authentication and participation friction

4. Database Schema and Query Patterns

The data access patterns for polls involve both rapid writes during voting and frequent reads for result aggregation. Interviewers assess whether your schema design supports both efficiently.

Hints to consider:

Separating vote storage from aggregate counts can optimize for different access patterns
Precomputed aggregates vs. on-demand calculation trade-offs
Partitioning strategies for isolating different polls or events
Time-series databases may be appropriate for vote timestamp analytics