Key Questions to Ask:

1. Scale Requirements:
   - How many operations per second?
   - How much data to store?
   - How many concurrent clients?
   - Geographic distribution needed?

2. Consistency Requirements:
   - Strong consistency or eventual consistency?
   - Can we tolerate stale reads?
   - ACID transactions needed?
   - What's acceptable replication lag?

3. Performance Requirements:
   - What's the target latency (P99)?
   - Read-heavy or write-heavy workload?
   - What's the read/write ratio?
   - Batch operations needed?

4. Availability Requirements:
   - What's the target uptime (99.9%, 99.99%)?
   - Can we have downtime for maintenance?
   - Multi-region deployment needed?
   - Disaster recovery requirements?

5. Data Characteristics:
   - Average key/value size?
   - Value size distribution?
   - TTL requirements?
   - Data types needed (strings, lists, sets)?

Start Simple:
┌─────────┐     ┌─────────────┐     ┌──────────┐
│ Clients │────→│ Load Balancer│────→│ KV Store │
└─────────┘     └─────────────┘     └──────────┘

Then Add Components:
- API Gateway for authentication
- Multiple storage nodes
- Replication for availability
- Caching for performance

Explain Consistent Hashing:
- Hash function for keys
- Virtual nodes for even distribution
- Replication factor (N=3)
- Preference list for each key

Draw the hash ring and show key placement

Choose LSM-Tree:
- Write-ahead log for durability
- MemTable for fast writes
- SSTables for persistent storage
- Compaction for space reclamation

Explain write and read paths

Quorum-Based Replication:
- N = replication factor
- W = write quorum
- R = read quorum
- R + W > N for strong consistency

Discuss trade-offs

Horizontal Scaling:
- Add nodes to increase capacity
- Rebalance data automatically
- No downtime during scaling

Performance Optimizations:
- Multi-level caching
- Bloom filters
- Compression
- Batch operations

Failure Scenarios:
- Node failures → Failover to replicas
- Network partitions → Quorum-based decisions
- Data corruption → Checksums and repair
- Cascading failures → Circuit breakers

❌ Bad: "We'll use RocksDB with LZ4 compression..."
✅ Good: "We need a storage engine. Let's discuss options..."

Start high-level, then drill down based on interviewer interest

❌ Bad: "We'll use strong consistency"
✅ Good: "Strong consistency gives us X but costs us Y. 
         Given our requirements, I'd choose..."

Always discuss trade-offs for major decisions

❌ Bad: Assume requirements and start designing
✅ Good: Ask about scale, consistency, latency requirements

Clarify ambiguities before diving into design

❌ Bad: Add every possible feature and optimization
✅ Good: Start simple, add complexity as needed

Build incrementally based on requirements

❌ Bad: Only discuss happy path
✅ Good: Proactively discuss failure handling

Show you think about reliability and edge cases

Explanation:
"We use consistent hashing to distribute data evenly across nodes.
Each node is assigned multiple virtual nodes (tokens) on a hash ring.
When a key comes in, we hash it and find the first node clockwise.
This ensures even distribution and minimal data movement when scaling."

Benefits:
- Even data distribution
- Minimal rebalancing when adding/removing nodes
- No single point of failure
- Automatic load balancing

Draw the hash ring to visualize

Explanation:
"We replicate each key to N nodes for availability. For writes, we wait
for W nodes to acknowledge. For reads, we query R nodes and return the
latest value. By ensuring R + W > N, we guarantee strong consistency."

Example:
N=3, W=2, R=2
- Write succeeds when 2 of 3 nodes acknowledge
- Read queries 2 of 3 nodes and returns latest
- Overlap ensures we always read latest write

Trade-offs:
- Higher W → stronger consistency, higher write latency
- Lower W → weaker consistency, lower write latency

Explanation:
"We use an LSM-tree for the storage engine. Writes go to an in-memory
MemTable and a write-ahead log for durability. When the MemTable fills,
we flush it to an immutable SSTable on disk. Reads check the MemTable
first, then SSTables using bloom filters to avoid unnecessary disk reads."

Benefits:
- Fast sequential writes
- Good compression
- Efficient for write-heavy workloads

Trade-offs:
- Read amplification (check multiple SSTables)
- Compaction overhead
- Variable read performance

Answer Structure:
1. Detection: Monitor access patterns, identify keys with >10K req/min
2. Mitigation:
   - Replicate hot key to more nodes (N=3 → N=10)
   - Cache hot key on all nodes
   - Split hot key into sub-keys if possible
   - Rate limit per-client access
3. Prevention: Design keys to avoid hotspots

Show you understand the problem and have multiple solutions

Answer Structure:
1. Immediate: Write continues if W nodes still available
2. Hinted Handoff: Store write for failed node
3. Recovery: Replay hints when node comes back
4. Repair: Background process ensures consistency

Walk through the failure scenario step-by-step

Answer Structure:
1. Async Replication: Replicate writes to other regions asynchronously
2. Conflict Resolution: Use vector clocks or last-write-wins
3. Trade-offs: Eventual consistency vs strong consistency
4. Options: Discuss multi-master vs single-master

Acknowledge the complexity and discuss trade-offs

0-5 min:   Clarify requirements
5-15 min:  High-level architecture
15-25 min: Deep dive into key components
25-35 min: Scaling and failure handling
35-40 min: Follow-up questions
40-45 min: Wrap-up and questions

Adjust based on interviewer's focus

✅ Asked clarifying questions upfront
✅ Started with simple design, added complexity
✅ Discussed trade-offs for major decisions
✅ Covered failure scenarios proactively
✅ Drew clear diagrams
✅ Explained reasoning clearly
✅ Adapted to interviewer feedback
✅ Showed depth in key areas

❌ Didn't ask any clarifying questions
❌ Jumped straight to implementation details
❌ Ignored trade-offs
❌ Couldn't explain design choices
❌ Didn't discuss failure handling
❌ Overengineered the solution
❌ Couldn't adapt to feedback
❌ Poor communication