System Design Problems: Core Challenges & Solutions

📋 Overview

A high-level mapping of common system design interview problems, identifying their "Critical Path" bottleneck and the architectural "Silver Bullet" used to solve it. This framework helps in breaking down complex prompts into manageable sub-problems.

---

🏗️ Core Principles & Characteristics

• The "Core Challenge" Identification: Every system has one thing that makes it hard (e.g., TinyURL = Unique ID, Netflix = Bandwidth).
• Key Solution Alignment: Matching the specific bottleneck to a specialized architectural primitive (e.g., Geo-search -> Geohashing).
• Trade-off Analysis: Understanding that every solution (e.g., Caching) introduces a new problem (e.g., Cache Invalidation).

---

⚖️ Trade-offs: Pros & Cons

Consistency vs. Availability (CAP)

• Pros of Strong Consistency: Predictable user experience, no "stale" data (critical for Banking).
• Cons of Strong Consistency: High latency, system becomes unavailable if the "Leader" node fails.

Latency vs. Storage

• Pros of Pre-computation (Fan-out): Instant read times for users (critical for News Feeds).
• Cons of Pre-computation: Massive storage overhead and high write-time latency.

---

🌍 Real-World Implementation

• Ticket Booking: Use Pessimistic Locking for the "Checkout" phase to ensure a seat isn't double-booked.
• Ride-Sharing (Uber): Use S2 Geometry or Geohash to find the nearest drivers in O(log N) time.
• Collaborative Docs: Use CRDTs (Conflict-free Replicated Data Types) for eventually consistent offline editing.
• Ad-Click Aggregator: Use MapReduce or Spark Streaming to process billions of clicks with exactly-once semantics.

---

💡 Interview "Gotchas" & Tips

• Don't Jump to Code: Start with the "Non-Functional Requirements" (NFRs). Is the system Read-Heavy or Write-Heavy?
• Scaling the ID: For TinyURL or Twitter, don't use auto-incrementing DB IDs. Mention Snowflake IDs or Ticket Servers.
• Data Partitioning: Always have a strategy for when one DB is full. Mention Consistent Hashing to avoid massive re-sharding.

---

📐 Suggested Architecture Primitives

• Storage: S3 for blobs, DynamoDB for metadata, Elasticsearch for search.
• Coordination: Zookeeper for leader election and service discovery.
• Streaming: Apache Flink or Kafka Streams for real-time analytics.
• Edge: Edge side includes (ESI) and CDN for global performance.