Functional Requirements:
- What types of events support live commenting? (sports, news, entertainment)
- Do we need threaded conversations or just flat comments?
- Should we support media attachments (images, videos, GIFs)?
- Do we need real-time reactions (likes, emojis) beyond comments?
- Is there a character limit for comments?
- Do we need comment moderation capabilities?

Non-Functional Requirements:
- How many concurrent users do we expect? (1M, 10M, 100M+)
- What's the expected peak comments per second?
- What's the acceptable latency for comment delivery?
- Do we need global distribution or specific regions?
- What's the uptime requirement? (99.9%, 99.99%)
- Do we need to store comment history? For how long?

Real-Time Constraints:
- How real-time does it need to be? (<100ms, <1s, <5s)
- Can we tolerate occasional message loss during peak traffic?
- Do comments need to be delivered in exact order?
- Should we support offline users and message replay?

Interviewer: "Design a live comment system for major sporting events."

You: "Great! Let me clarify a few key requirements:

1. Scale: Are we talking about events like the Super Bowl with 100M+ concurrent viewers, 
   or smaller events with maybe 1M viewers?

2. Real-time: What's the acceptable latency? For live sports, I imagine sub-second 
   delivery is important for the experience.

3. Features: Beyond basic commenting, do we need:
   - Threaded replies to comments?
   - Real-time reactions (thumbs up, emojis)?
   - Media sharing (photos, GIFs)?
   - Comment moderation for inappropriate content?

4. Reliability: Can we tolerate some comment loss during extreme traffic spikes, 
   or is every comment critical?

5. Geography: Is this global or focused on specific regions like North America?"

Interviewer: "Let's say Super Bowl scale - 100M viewers, 10M active commenters, 
sub-200ms latency, basic comments with reactions, some comment loss acceptable 
during peaks, global system."

You: "Perfect! So we're designing for:
- 100M concurrent viewers
- 10M active commenters  
- Peak of ~500K comments/second during key moments
- <200ms comment delivery latency
- Global distribution
- Basic comments + reactions
- Eventual consistency acceptable"

"Let me start with a high-level architecture and then dive into each component:

┌─────────────┐    ┌─────────────┐    ┌─────────────┐
│   Clients   │────│Load Balancer│────│  API Gateway │
│(Web/Mobile) │    │             │    │             │
└─────────────┘    └─────────────┘    └─────────────┘
                                              │
                   ┌─────────────────────────────────────┐
                   │                                     │
            ┌─────────────┐                    ┌─────────────┐
            │ WebSocket   │                    │   REST API  │
            │ Servers     │                    │  Servers    │
            └─────────────┘                    └─────────────┘
                   │                                     │
            ┌─────────────┐                    ┌─────────────┐
            │ Message     │                    │ Database    │
            │ Queue       │                    │ Cluster     │
            │ (Kafka)     │                    │(Cassandra)  │
            └─────────────┘                    └─────────────┘

The key insight here is separating the real-time delivery path (WebSocket + Kafka) 
from the persistence path (REST API + Database). This allows us to optimize each 
for their specific requirements."

"I'm choosing this architecture because:

1. WebSocket servers handle real-time bidirectional communication
2. Kafka provides reliable message queuing and fan-out
3. Cassandra offers high write throughput for comment storage
4. Separation allows independent scaling of each component

The flow is:
1. User submits comment via WebSocket
2. Comment goes to Kafka for reliable processing
3. Kafka fans out to: WebSocket delivery + Database persistence
4. Real-time users get immediate delivery, database stores for history"

Interviewer: "How do you handle 100M WebSocket connections?"

You: "Great question! WebSocket connections are the main bottleneck. Here's my approach:

1. Connection Distribution:
   - Each server handles ~50K connections (conservative estimate)
   - Need ~2000 servers for 100M connections
   - Use consistent hashing on event_id for connection affinity

2. Connection Management:
   ┌─────────────┐    ┌─────────────┐    ┌─────────────┐
   │   Server 1  │    │   Server 2  │    │   Server N  │
   │ 50K conns   │    │ 50K conns   │    │ 50K conns   │
   └─────────────┘    └─────────────┘    └─────────────┘
           │                  │                  │
           └──────────────────┼──────────────────┘
                              │
                    ┌─────────────┐
                    │   Kafka     │
                    │  Cluster    │
                    └─────────────┘

3. Key Optimizations:
   - Sticky sessions to avoid connection migration
   - Connection pooling and reuse
   - Heartbeat mechanisms for connection health
   - Graceful degradation during server failures

4. Auto-scaling:
   - Monitor CPU/memory usage per server
   - Scale up when connections > 40K per server
   - Use Kubernetes HPA with custom metrics"

Interviewer: "How do you design the database for 500K writes/second?"

You: "I'd use Cassandra for its excellent write performance. Here's the schema design:

CREATE TABLE comments (
    event_id UUID,           -- Partition key
    comment_time TIMESTAMP,  -- Clustering key 1
    comment_id UUID,         -- Clustering key 2
    user_id UUID,
    content TEXT,
    like_count INT,
    created_at TIMESTAMP,
    PRIMARY KEY ((event_id), comment_time, comment_id)
) WITH CLUSTERING ORDER BY (comment_time DESC, comment_id ASC);

Key Design Decisions:

1. Partitioning Strategy:
   - Partition by event_id for even distribution
   - Each event gets its own partition
   - Avoids hot partitions during popular events

2. Clustering Strategy:
   - Order by comment_time DESC for recent-first queries
   - comment_id as secondary sort for deterministic ordering
   - Enables efficient time-range queries

3. Write Optimization:
   - Use LOCAL_QUORUM consistency for fast writes
   - Time-window compaction strategy
   - Batch writes when possible

4. Scaling:
   - Start with 50 nodes across 3 datacenters
   - Each node handles ~10K writes/second
   - Linear scaling by adding nodes"

Interviewer: "How does Kafka handle the message distribution?"

You: "Kafka is perfect for this fan-out pattern. Here's the setup:

Topic Design:
- comment_events: 100 partitions, replication factor 3
- Partition by event_id for ordering within events
- Retention: 24 hours (enough for replay)

Consumer Groups:
1. websocket_delivery: Real-time delivery to connected users
2. database_persistence: Store comments in Cassandra  
3. moderation_pipeline: Content moderation processing
4. analytics_stream: Real-time analytics processing

┌─────────────┐    ┌─────────────────────────────────┐
│  Producer   │────│        Kafka Cluster           │
│ (WebSocket) │    │  ┌─────┐ ┌─────┐ ┌─────┐      │
└─────────────┘    │  │ P1  │ │ P2  │ │ PN  │      │
                   │  └─────┘ └─────┘ └─────┘      │
                   └─────────────────────────────────┘
                              │
                   ┌──────────┼──────────┐
                   │          │          │
            ┌─────────┐ ┌─────────┐ ┌─────────┐
            │WebSocket│ │Database │ │Analytics│
            │Consumer │ │Consumer │ │Consumer │
            └─────────┘ └─────────┘ └─────────┘

Performance Characteristics:
- 1M+ messages/second throughput
- <10ms producer latency
- Parallel processing across partitions
- Automatic failover and rebalancing"

Interviewer: "What happens during a touchdown in the Super Bowl when comments spike 10x?"

You: "Excellent question! This is where our architecture really shines:

1. Immediate Response (0-10 seconds):
   - Kafka absorbs the write spike with its high throughput
   - WebSocket servers continue delivering at their max capacity
   - Some users may experience slight delay, but no failures

2. Auto-scaling Response (10-60 seconds):
   - Kubernetes HPA detects high CPU/connection count
   - Spins up additional WebSocket servers
   - Load balancer distributes new connections

3. Graceful Degradation:
   - If overwhelmed, switch some users to polling mode
   - Prioritize delivery to premium users or key regions
   - Show 'high traffic' indicator to set expectations

4. Recovery (1-5 minutes):
   - Traffic normalizes after the spike
   - Auto-scaler reduces server count
   - All users back to real-time mode

The key is designing for graceful degradation rather than complete failure."

Interviewer: "How do you handle global users with low latency?"

You: "Multi-region deployment with edge optimization:

Regional Architecture:
┌─────────────┐  ┌─────────────┐  ┌─────────────┐
│  US-East    │  │  EU-West    │  │ AP-Southeast│
│             │  │             │  │             │
│ WebSocket   │  │ WebSocket   │  │ WebSocket   │
│ Servers     │  │ Servers     │  │ Servers     │
│             │  │             │  │             │
│ Kafka       │  │ Kafka       │  │ Kafka       │
│ Cluster     │  │ Cluster     │  │ Cluster     │
└─────────────┘  └─────────────┘  └─────────────┘
       │                 │                 │
       └─────────────────┼─────────────────┘
                         │
              ┌─────────────────┐
              │ Global Cassandra│
              │    Cluster      │
              └─────────────────┘

Strategy:
1. Users connect to nearest region for <50ms latency
2. Comments replicate globally via Kafka cross-region
3. Cassandra provides global eventual consistency
4. CDN caches popular content and user profiles

Trade-offs:
- Slight delay for cross-region comment visibility (~100-200ms)
- Increased infrastructure complexity
- Better user experience globally"

A: "Great question! Comment ordering is tricky in distributed systems. Here are the approaches:

1. Timestamp-based Ordering (What I'd recommend):
   - Use server-side timestamps when comment arrives
   - Store in Cassandra with timestamp as clustering key
   - Clients display in timestamp order
   - Handles clock skew and network delays

2. Sequence Number Approach:
   - Global sequence generator (like Twitter Snowflake)
   - Guarantees total ordering
   - More complex, potential bottleneck

3. Vector Clocks (For causal ordering):
   - Track causal relationships between comments
   - More complex but handles network partitions
   - Overkill for most live comment scenarios

For live comments, I'd use server timestamps because:
- Simple to implement and understand
- Good enough ordering for user experience  
- Handles the 99% case well
- Can add sequence numbers later if needed

The key insight is that perfect ordering isn't always necessary - 
users care more about seeing recent comments quickly than perfect chronological order."

A: "WebSocket reliability is crucial for user experience. Here's my approach:

Client-Side Reconnection Strategy:
```javascript
class ReliableWebSocket {
    constructor(url) {
        this.url = url;
        this.reconnectDelay = 1000; // Start with 1 second
        this.maxReconnectDelay = 30000; // Max 30 seconds
        this.reconnectAttempts = 0;
        this.maxReconnectAttempts = 10;
    }
    
    connect() {
        this.ws = new WebSocket(this.url);
        
        this.ws.onopen = () => {
            console.log('Connected');
            this.reconnectDelay = 1000; // Reset delay
            this.reconnectAttempts = 0;
            this.requestMissedMessages(); // Get messages sent while disconnected
        };
        
        this.ws.onclose = () => {
            this.scheduleReconnect();
        };
    }
    
    scheduleReconnect() {
        if (this.reconnectAttempts < this.maxReconnectAttempts) {
            setTimeout(() => {
                this.reconnectAttempts++;
                this.connect();
            }, this.reconnectDelay);
            
            // Exponential backoff with jitter
            this.reconnectDelay = Math.min(
                this.reconnectDelay * 2 + Math.random() * 1000,
                this.maxReconnectDelay
            );
        }
    }
}

**Q: "How do you implement content moderation at scale?"**

### System Design Patterns

**Q: "How would you modify this system for different use cases like Twitch chat or Twitter Spaces?"**

## Interview Best Practices

### Do's and Don'ts

**DO:**
- Start with clarifying questions - shows you understand requirements matter
- Begin with simple architecture, then add complexity
- Explain your reasoning for each design decision
- Discuss trade-offs explicitly ("I'm choosing X over Y because...")
- Consider failure scenarios and how to handle them
- Think about monitoring and observability
- Mention specific technologies but focus on concepts
- Draw diagrams to illustrate your points
- Ask for feedback ("Does this approach make sense?")

**DON'T:**
- Jump straight into implementation details
- Ignore the scale requirements
- Forget about failure scenarios
- Over-engineer the initial solution
- Get stuck on one component for too long
- Ignore the interviewer's hints or questions
- Assume perfect network conditions
- Forget about operational concerns (monitoring, deployment)

### Time Management Strategy

**Minutes 0-5: Requirements Gathering**
- Clarify functional requirements
- Understand scale constraints
- Identify key performance metrics

**Minutes 5-15: High-Level Design**
- Draw overall architecture
- Identify major components
- Explain data flow

**Minutes 15-35: Deep Dives**
- Focus on 2-3 critical components
- Discuss database design
- Cover scaling strategies
- Address failure scenarios

**Minutes 35-40: Wrap-up**
- Summarize key decisions
- Discuss monitoring and operations
- Mention potential improvements

**Minutes 40-45: Q&A**
- Answer follow-up questions
- Clarify any unclear points
- Discuss alternative approaches

### Key Talking Points to Remember

1. **Real-time systems prioritize availability over consistency**
2. **WebSocket scaling is the primary bottleneck**
3. **Message queues enable reliable fan-out patterns**
4. **Graceful degradation is better than complete failure**
5. **Global distribution requires careful consistency trade-offs**
6. **Content moderation must balance speed with accuracy**
7. **Monitoring and alerting are crucial for live systems**
8. **Auto-scaling helps handle unpredictable traffic spikes**

Remember: The goal isn't to design the perfect system, but to demonstrate your thought process, technical knowledge, and ability to make reasonable trade-offs under constraints.