Phase 1: Requirements Gathering (5-10 minutes)
- Clarify functional requirements
- Understand scale and constraints
- Identify critical features vs nice-to-have
- Ask about existing infrastructure

Phase 2: High-Level Design (10-15 minutes)
- Draw system architecture diagram
- Identify major components
- Explain data flow
- Discuss technology choices

Phase 3: Deep Dive (15-20 minutes)
- Focus on 2-3 critical components
- Database schema design
- API design
- Scaling strategies

Phase 4: Tradeoffs and Alternatives (5-10 minutes)
- Discuss design decisions
- Explain tradeoffs
- Mention alternatives considered
- Address bottlenecks

Phase 5: Wrap-up (5 minutes)
- Monitoring and operations
- Security considerations
- Future improvements
- Answer follow-up questions

Geospatial Indexing:
✓ "I'll use Redis with GEORADIUS for real-time driver queries"
✓ "S2 Geometry library for spatial indexing and cell-based sharding"
✓ "Query complexity is O(log n) with geospatial index"
✗ Avoid: "I'll query all drivers and filter by distance" (too slow)

Matching Algorithm:
✓ "Score drivers based on distance, rating, acceptance rate"
✓ "Send offers to top 3 drivers simultaneously"
✓ "First to accept wins, with 15-second timeout"
✗ Avoid: "Match with nearest driver only" (suboptimal)

Scalability:
✓ "Shard by city for geographic locality"
✓ "Handle 15K matching requests per second at peak"
✓ "Parallel matching across multiple service instances"
✗ Avoid: "Single matching service" (bottleneck)

"For the matching system, I'll use a multi-step approach:

1. Geospatial Query: Use Redis GEORADIUS to find drivers within 5km 
   of pickup location. This gives us ~50 candidate drivers in <10ms.

2. Filtering: Filter by vehicle type, driver status, and minimum rating.
   This reduces candidates to ~20 drivers.

3. Scoring: Calculate composite score for each driver:
   - Distance to pickup (40% weight)
   - Driver rating (20% weight)
   - Acceptance rate (15% weight)
   - Earnings balance (15% weight)
   - Time since last trip (10% weight)

4. Selection: Rank drivers by score and send offers to top 3 simultaneously.
   First to accept gets the trip.

5. Retry: If no acceptance in 15 seconds, expand search radius and retry.

This approach balances speed (<5 seconds), fairness, and optimization.
For scale, I'll shard by city and run multiple matching service instances."

Data Volume:
✓ "750K location updates per second from 3M active drivers"
✓ "Use Kafka for buffering and stream processing"
✓ "Batch updates to reduce network overhead"
✗ Avoid: "Store every GPS point in database" (too expensive)

Real-time Processing:
✓ "Update Redis geospatial index in real-time"
✓ "Store historical data in Cassandra (time-series)"
✓ "Async processing for non-critical updates"
✗ Avoid: "Synchronous database writes" (too slow)

Optimization:
✓ "Adaptive update frequency (faster during trips)"
✓ "Compression to reduce bandwidth"
✓ "Dead reckoning during GPS signal loss"
✗ Avoid: "Fixed 1-second update interval" (battery drain)

"For GPS tracking, I need to handle 750K updates per second:

1. Ingestion: Driver apps send location updates every 4 seconds.
   Updates go through load balancer to Location API, then to Kafka.

2. Stream Processing: Kafka consumers process updates:
   - Update Redis geospatial index (for real-time queries)
   - Write to Cassandra (for historical data)
   - Trigger geofence events (arrival detection)

3. Optimization:
   - Batch 5 updates together to reduce network calls
   - Compress payloads (100 bytes → 50 bytes)
   - Adaptive frequency: 4s normally, 2s during trips

4. Reliability:
   - Queue updates locally when offline
   - Retry with exponential backoff
   - Detect and handle GPS spoofing

This architecture handles high throughput while maintaining low latency."

Reliability:
✓ "Async payment processing with retry logic"
✓ "Idempotency keys to prevent duplicate charges"
✓ "Multiple payment gateway failover"
✗ Avoid: "Synchronous payment blocking trip completion"

Security:
✓ "PCI DSS Level 1 compliance"
✓ "Tokenization (never store card numbers)"
✓ "Fraud detection with ML models"
✗ Avoid: "Store credit card numbers in database"

Scale:
✓ "1,800 transactions per second at peak"
✓ "Kafka for async processing and load leveling"
✓ "Separate payment service for isolation"
✗ Avoid: "Process payments in main API service"

"For payments, I'll prioritize reliability and security:

1. Authorization: When trip starts, authorize payment method
   (hold funds but don't capture yet).

2. Trip Completion: When trip ends, immediately update trip status.
   Don't wait for payment to complete.

3. Async Capture: Publish payment event to Kafka. Payment service
   processes asynchronously:
   - Calculate final fare
   - Run fraud check
   - Capture payment
   - Retry on failure (3 attempts with exponential backoff)

4. Failover: Use multiple payment gateways:
   - Primary: Stripe (70% traffic)
   - Secondary: Braintree (20% traffic)
   - Tertiary: Adyen (10% traffic)
   - Circuit breaker for automatic failover

5. Security:
   - Tokenization (Stripe tokens, never store cards)
   - PCI DSS compliance
   - Fraud detection (ML model scoring each transaction)

This ensures trips complete quickly even if payment processing is slow."

Sharding:
✓ "Shard by city_id for geographic locality"
✓ "500 shards globally, 1 primary + 2 replicas each"
✓ "95% of queries stay within single shard"
✗ Avoid: "Single database" or "No sharding strategy"

Polyglot Persistence:
✓ "PostgreSQL for transactional data (trips, payments)"
✓ "Cassandra for time-series data (GPS locations)"
✓ "Redis for real-time data (driver locations, cache)"
✗ Avoid: "Use one database for everything"

Optimization:
✓ "Comprehensive indexing strategy"
✓ "Read replicas for scaling reads"
✓ "Caching at multiple layers"
✗ Avoid: "No caching" or "Cache everything"

"I'll use polyglot persistence for optimal performance:

1. PostgreSQL (Transactional Data):
   - Trips, users, drivers, payments
   - Shard by city_id (geographic locality)
   - 500 shards, each with 1 primary + 2 read replicas
   - ACID compliance for financial transactions

2. Cassandra (Time-Series Data):
   - GPS location history
   - High write throughput (750K writes/second)
   - Time-based partitioning
   - 90-day retention with automatic deletion

3. Redis (Real-Time Data):
   - Driver locations (geospatial index)
   - Session management
   - Caching (user profiles, trip data)
   - Pub/sub for real-time updates

4. Elasticsearch (Search):
   - Trip search
   - Driver search
   - Analytics queries

This approach optimizes for each data access pattern."

❌ Bad: "I'll use blockchain for trip records"
✓ Good: "I'll use PostgreSQL with audit logging"

❌ Bad: "I'll implement custom consensus algorithm"
✓ Good: "I'll use proven solutions like Raft/Paxos"

❌ Bad: "I'll build custom message queue"
✓ Good: "I'll use Kafka for event streaming"

Key Point: Use proven technologies, don't reinvent the wheel

❌ Bad: "I'll use a single database server"
✓ Good: "I'll shard across 500 database servers"

❌ Bad: "I'll query all drivers and filter"
✓ Good: "I'll use geospatial index for O(log n) queries"

❌ Bad: "I'll process payments synchronously"
✓ Good: "I'll use async processing with Kafka"

Key Point: Always consider scale from the beginning

❌ Bad: "Assume network is always reliable"
✓ Good: "Implement retry logic with exponential backoff"

❌ Bad: "Single payment gateway"
✓ Good: "Multiple gateways with automatic failover"

❌ Bad: "No monitoring or alerting"
✓ Good: "Comprehensive monitoring with automated alerts"

Key Point: Design for failure, not just success

❌ Bad: "I'll use a database"
✓ Good: "I'll use PostgreSQL sharded by city_id"

❌ Bad: "I'll cache some data"
✓ Good: "I'll cache driver locations in Redis with 5-second TTL"

❌ Bad: "I'll make it scalable"
✓ Good: "I'll horizontally scale to 5,000 application servers"

Key Point: Be specific with numbers and technologies

"For the matching algorithm, I considered three approaches:

1. Greedy (nearest driver):
   Pros: Fast, simple
   Cons: Suboptimal for driver earnings
   
2. Optimal (Hungarian algorithm):
   Pros: Globally optimal
   Cons: Too slow (O(n³)), requires batching
   
3. Scored matching (my choice):
   Pros: Fast (<5s), better than greedy, considers multiple factors
   Cons: Not globally optimal
   
I chose scored matching because it balances speed and optimization."

"At Uber's scale (50M trips/day), we need to think about:

1. Database: Can't use single database, need 500 shards
2. Caching: Must cache aggressively to reduce database load
3. Async Processing: Can't block on slow operations
4. Geographic Distribution: Need regional data centers
5. Cost: $3.8M/month infrastructure, must optimize

Every design decision must consider these constraints."

"Beyond the technical design, we need to consider:

1. Regulatory: Different rules per city/country
2. Safety: Driver verification, trip monitoring
3. Fraud: Payment fraud, fake trips, rating manipulation
4. Privacy: GDPR, CCPA compliance
5. Operations: 24/7 support, incident response

These aren't just technical problems, they're business problems."

Structure:
1. Clarify the requirement
2. State your approach
3. Explain the tradeoffs
4. Mention alternatives
5. Discuss scale implications

Example:
Q: "How would you handle GPS inaccuracies?"

A: "GPS inaccuracies are common in urban canyons and tunnels.
   
   My approach:
   1. Dead Reckoning: Use accelerometer/gyroscope to estimate position
   2. Map Matching: Snap GPS coordinates to nearest road
   3. Sensor Fusion: Combine multiple sensors with Kalman filter
   4. Fallback: Use cell tower triangulation or WiFi positioning
   
   Tradeoff: More complex but better accuracy
   
   At scale: Need to process 750K updates/second, so algorithms
   must be efficient (O(1) or O(log n))."

Structure:
1. Identify the failure scenario
2. Explain the impact
3. Describe mitigation strategy
4. Discuss recovery process

Example:
Q: "What if the payment gateway goes down?"

A: "Payment gateway failure would prevent trip payments.
   
   Impact: Riders can't be charged, drivers don't get paid
   
   Mitigation:
   1. Multiple Gateways: Stripe, Braintree, Adyen
   2. Circuit Breaker: Detect failures, route to backup
   3. Async Processing: Queue payments for retry
   4. Graceful Degradation: Allow trips to complete
   
   Recovery:
   1. Process queued payments when gateway recovers
   2. Retry failed payments (3 attempts over 7 days)
   3. Manual intervention for permanent failures
   
   This ensures trips aren't blocked by payment issues."

❌ "I don't know" (without trying to reason through it)
✓ "I'm not familiar with that specific technology, but here's how I'd approach it..."

❌ "That's impossible to scale"
✓ "That's challenging at scale, here are some approaches..."

❌ "Just use microservices" (without justification)
✓ "Microservices make sense here because..."

❌ "Security isn't my area"
✓ "For security, I'd implement encryption, authentication, and..."

❌ "I'd use the latest technology X"
✓ "I'd use proven technology X because..."

"To summarize my Uber backend design:

1. Matching: Geospatial indexing with scored matching (<5s latency)
2. Location: Kafka-based streaming (750K updates/second)
3. Payments: Async processing with multiple gateways (1,800 TPS)
4. Database: Polyglot persistence with city-based sharding
5. Scale: 5,000 app servers, 500 database shards, 10+ regions

Key strengths:
- Handles 50M trips/day
- Sub-second response times
- High availability (99.99%)
- Fault tolerant with graceful degradation

Areas for improvement:
- ML-based demand prediction
- More sophisticated fraud detection
- Better driver earnings optimization

I'm happy to dive deeper into any component."