1. Requirements (5-8 min)
   - Clarify functional requirements
   - Understand scale constraints
   - Define success metrics

2. High-Level Design (10-15 min)
   - Draw system architecture
   - Explain major components
   - Discuss data flow

3. Deep Dives (20-25 min)
   - Partition and replication
   - Producer/consumer protocols
   - Storage and indexing
   - Failure handling

4. Trade-offs (5-10 min)
   - Delivery semantics
   - Consistency models
   - Performance vs durability

5. Follow-ups (5-10 min)
   - Scaling strategies
   - Security considerations
   - Monitoring and operations

Critical Questions:
1. "What delivery guarantees do we need?"
   - At-most-once, at-least-once, or exactly-once?
   
2. "Do we need message ordering?"
   - Global ordering or partition-level?
   
3. "What's the message retention policy?"
   - Time-based (7 days) or size-based (100GB)?
   
4. "Do we need replay capability?"
   - Yes → Log-based storage
   - No → Queue-based deletion
   
5. "What's the expected message size?"
   - Small (1KB) → Optimize for throughput
   - Large (10MB) → Optimize for bandwidth

Good Follow-ups:
- "Should we support multiple consumers per message?"
- "Do we need message filtering at the broker?"
- "What about dead letter queues for failed messages?"

Key Metrics:
1. "How many messages per second?"
   - 1K → Single broker
   - 100K → Small cluster (3-5 brokers)
   - 1M+ → Large cluster (10+ brokers)
   
2. "How many topics and partitions?"
   - Affects metadata overhead
   - Impacts rebalancing time
   
3. "How many producers and consumers?"
   - Affects connection management
   - Impacts network bandwidth
   
4. "What's the acceptable latency?"
   - <10ms → Optimize for speed
   - <100ms → Balanced approach
   - <1s → Optimize for throughput

❌ Bad: "We'll store messages in a queue"

✅ Good: "We'll partition the topic into multiple partitions 
for parallelism. Messages with the same key go to the same 
partition to maintain ordering. We'll use hash(key) % 
num_partitions for distribution."

Key Points:
- Explain partitioning strategy
- Discuss ordering guarantees
- Address hot partition problem

❌ Bad: "We'll store messages on disk"

✅ Good: "We'll replicate each partition 3 times across 
different brokers. One replica is the leader handling 
reads/writes, others are followers. We'll use ISR (in-sync 
replicas) to ensure durability. On leader failure, we elect 
a new leader from ISR."

Key Points:
- Explain replication factor
- Discuss leader election
- Address data durability

❌ Bad: "Consumers will read messages"

✅ Good: "We'll use consumer groups for load balancing. 
Each partition is assigned to one consumer in the group. 
When consumers join/leave, we trigger rebalancing to 
redistribute partitions. This allows horizontal scaling 
of consumers."

Key Points:
- Explain consumer group protocol
- Discuss partition assignment
- Address rebalancing

❌ Bad: "The system will be reliable"

✅ Good: "For broker failures, we have replicas that can 
take over. For network partitions, we use quorum-based 
decisions. For slow consumers, we have configurable 
retention to prevent data loss. For poison messages, 
we implement dead letter queues."

Key Points:
- Enumerate failure scenarios
- Provide specific solutions
- Discuss trade-offs

Strong Answer:
"I'll use a log-based storage model similar to Kafka. 
Each partition is an append-only log stored as segment 
files on disk. This provides several benefits:

1. Sequential writes are fast (500MB/s on SSD)
2. Multiple consumers can read independently
3. Messages are durable and replayable
4. Simple data structure (offset-based access)

The log is divided into 1GB segments. Each segment has:
- .log file: Actual messages
- .index file: Offset → file position mapping
- .timeindex file: Timestamp → offset mapping

For retention, we delete old segments after 7 days or 
when disk usage exceeds threshold. This is much simpler 
than per-message deletion."

Why This Works:
- Shows deep understanding
- Explains benefits clearly
- Provides implementation details
- Discusses trade-offs

Strong Answer:
"For replication, I'll use a leader-follower model with 
3 replicas per partition:

Leader:
- Handles all reads and writes
- Maintains ISR (in-sync replicas) list
- Updates high watermark

Followers:
- Fetch from leader continuously
- Replicate to local log
- Send acknowledgments

For consistency, we have two options:

Option 1: Synchronous (acks=all)
- Wait for all ISR to acknowledge
- No data loss on leader failure
- Higher latency (+3-5ms)
- Use for critical data

Option 2: Asynchronous (acks=1)
- Leader acknowledges immediately
- Possible data loss (small window)
- Lower latency (<2ms)
- Use for logs and metrics

I'd recommend acks=all for critical data and acks=1 for 
high-throughput use cases. We can configure this per topic."

Why This Works:
- Clear explanation of replication
- Discusses consistency trade-offs
- Provides specific recommendations
- Shows practical thinking

Strong Answer:
"For consumer scaling, I'll implement consumer groups:

Protocol:
1. Consumers join group via coordinator (broker)
2. Coordinator triggers rebalancing
3. Group leader assigns partitions
4. Consumers start consuming assigned partitions

Partition Assignment Strategies:
- Range: Consecutive partitions (simple but uneven)
- Round-robin: Even distribution
- Sticky: Minimize partition movement
- Cooperative: Incremental rebalancing (recommended)

For offset management:
- Store offsets in __consumer_offsets topic
- Commit after processing (at-least-once)
- Commit before processing (at-most-once)
- Transactional commits (exactly-once)

Rebalancing Optimization:
- Use cooperative sticky assignor
- Increase session.timeout.ms to reduce false positives
- Tune max.poll.interval.ms for processing time
- Monitor rebalance frequency (should be <1/hour)"

Why This Works:
- Comprehensive explanation
- Multiple strategies discussed
- Practical optimizations
- Shows operational awareness

Strong Answer:
"Great question. Slow consumers are a common issue. 
Here's my approach:

1. Detection:
   - Monitor consumer lag (current offset vs log end offset)
   - Alert when lag > 10K messages
   - Track processing time per message

2. Immediate Actions:
   - Add more consumers to the group (horizontal scaling)
   - Increase max.poll.records for batch processing
   - Optimize consumer processing logic

3. Long-term Solutions:
   - Increase partition count for more parallelism
   - Use async processing with thread pools
   - Implement backpressure handling
   - Consider separate topics for slow processing

4. Prevent Data Loss:
   - Configure retention.ms > max expected lag time
   - Monitor disk usage
   - Alert before retention expires

The key is monitoring and alerting early, then scaling 
horizontally by adding consumers."

Why This Works:
- Structured approach (detect, act, prevent)
- Multiple solutions
- Practical recommendations
- Shows operational maturity

Strong Answer:
"Exactly-once is challenging in distributed systems. 
Here's how I'd implement it:

Producer Side:
1. Enable idempotent producer
   - Kafka assigns producer ID and sequence number
   - Broker deduplicates based on these
   - Handles retries automatically

2. Use transactions
   - Begin transaction
   - Send multiple messages
   - Commit atomically
   - All or nothing guarantee

Consumer Side:
1. Read committed isolation level
   - Only see committed messages
   - Skip aborted transactions

2. Transactional processing
   - Read messages
   - Process and produce output
   - Commit offsets transactionally
   - Atomic read-process-write

Trade-offs:
- 30% throughput reduction
- 20-30ms latency increase
- More complex error handling
- Higher resource usage

I'd use exactly-once only for critical use cases like 
financial transactions. For most use cases, at-least-once 
with idempotent processing is sufficient and more efficient."

Why This Works:
- Complete solution (producer + consumer)
- Explains implementation details
- Discusses trade-offs
- Provides practical guidance

1. "We'll use a database to store messages"
   → Shows lack of understanding of messaging systems

2. "We don't need replication"
   → Ignores durability requirements

3. "All messages will be ordered globally"
   → Unrealistic for high-throughput systems

4. "Consumers will poll every millisecond"
   → Inefficient, shows poor understanding

5. "We'll handle failures later"
   → Lack of system design thinking

1. "Let me clarify the requirements first"
   → Shows structured thinking

2. "Here are three approaches with trade-offs"
   → Demonstrates options analysis

3. "For this scale, we need partitioning"
   → Shows scalability awareness

4. "The consistency-availability trade-off is..."
   → Understands distributed systems

5. "We'll monitor these key metrics"
   → Shows operational maturity

"To summarize, I've designed a distributed messaging system 
that:

1. Uses log-based storage for durability and replay
2. Partitions topics for horizontal scalability
3. Replicates data 3x for fault tolerance
4. Supports consumer groups for load balancing
5. Provides configurable delivery guarantees
6. Handles 1M+ messages/second with <10ms latency

Key design decisions:
- Partition-level ordering (not global)
- Leader-follower replication
- At-least-once delivery by default
- Cooperative consumer rebalancing

Areas for future improvement:
- Tiered storage for cost optimization
- Schema registry for evolution
- Multi-region replication for DR

I'm happy to dive deeper into any specific area."

Why This Works:
- Concise summary
- Highlights key decisions
- Shows forward thinking
- Invites discussion