| export interface SystemDesignTopic { |
| id: string; |
| title: string; |
| category: string; |
| description: string; |
| answer: { |
| overview: string; |
| keyComponents: string[]; |
| tradeoffs: string[]; |
| diagramData?: any; |
| }; |
| } |
|
|
| export const systemDesignData: Record<string, SystemDesignTopic[]> = { |
| "Basics": [ |
| { id: "sd-1", category: "Basics", title: "What is System Design?", description: "Fundamental concepts of designing large-scale distributed systems.", answer: { overview: "System design is the process of defining the architecture, modules, interfaces, and data for a system to satisfy specified requirements.", keyComponents: ["Requirements Gathering", "High-Level Design", "Low-Level Design"], tradeoffs: ["Complexity vs. Performance"] } }, |
| { id: "sd-2", category: "Basics", title: "Functional vs Non-Functional Requirements", description: "Differentiating between what the system does and how it performs.", answer: { overview: "Functional: What it does. Non-Functional: How it performs (Scalability, Availability).", keyComponents: ["Use Cases", "SLAs", "Performance Metrics"], tradeoffs: ["Speed vs. Cost"] } }, |
| { id: "sd-3", category: "Basics", title: "Scalability (Vertical vs Horizontal)", description: "Strategies for handling increased load.", answer: { overview: "Vertical: Bigger machines. Horizontal: More machines.", keyComponents: ["Load Balancers", "Auto-scaling"], tradeoffs: ["Cost vs. Complexity"] } }, |
| { id: "sd-4", category: "Basics", title: "Latency vs Throughput", description: "Measuring system performance.", answer: { overview: "Latency: Time for one request. Throughput: Requests per second.", keyComponents: ["Response Time", "QPS"], tradeoffs: ["Low Latency vs. High Throughput"] } }, |
| { id: "sd-5", category: "Basics", title: "CAP Theorem (intro level)", description: "Consistency, Availability, Partition Tolerance.", answer: { overview: "In a distributed system, you can only pick two out of three.", keyComponents: ["Consistency", "Availability", "Partition Tolerance"], tradeoffs: ["CP vs AP"] } }, |
| { id: "sd-6", category: "Basics", title: "Monolith vs Distributed Systems", description: "Architectural styles.", answer: { overview: "Monolith: Single unit. Distributed: Multiple communicating units.", keyComponents: ["Microservices", "RPC"], tradeoffs: ["Simplicity vs. Scalability"] } }, |
| { id: "sd-7", category: "Basics", title: "High-Level Architecture (HLD vs LLD)", description: "Design phases.", answer: { overview: "HLD: System overview. LLD: Detailed component logic.", keyComponents: ["Diagrams", "Class Designs"], tradeoffs: ["Abstraction vs. Detail"] } }, |
| { id: "sd-8", category: "Basics", title: "Client-Server Architecture", description: "Standard communication model.", answer: { overview: "Clients request, servers respond.", keyComponents: ["API", "Protocols"], tradeoffs: ["Centralization vs. Decentralization"] } }, |
| { id: "sd-9", category: "Basics", title: "Stateless vs Stateful Systems", description: "Managing session data.", answer: { overview: "Stateless: No stored session. Stateful: Remembers client state.", keyComponents: ["Sessions", "JWT"], tradeoffs: ["Scalability vs. Convenience"] } }, |
| { id: "sd-10", category: "Basics", title: "Fault Tolerance & Reliability", description: "Handling failures.", answer: { overview: "System continues to operate despite failures.", keyComponents: ["Redundancy", "Failover"], tradeoffs: ["Cost vs. Uptime"] } }, |
| { id: "sd-11", category: "Basics", title: "Availability Basics", description: "Uptime percentage.", answer: { overview: "Percentage of time system is operational (e.g., 99.9%).", keyComponents: ["Uptime", "Downtime"], tradeoffs: ["Cost of 9s"] } }, |
| { id: "sd-12", category: "Basics", title: "Performance Metrics (QPS, TPS)", description: "Measuring load.", answer: { overview: "Queries Per Second (QPS), Transactions Per Second (TPS).", keyComponents: ["Throughput", "Load Testing"], tradeoffs: ["Accuracy vs. Speed"] } } |
| ], |
| "Load Balancing": [ |
| { id: "sd-lb-1", category: "Load Balancing", title: "Types of Load Balancers (L4 vs L7)", description: "Transport vs Application layer.", answer: { overview: "L4: IP/Port based. L7: Content/URL based.", keyComponents: ["TCP", "HTTP"], tradeoffs: ["Speed vs. Intelligence"] } }, |
| { id: "sd-lb-2", category: "Load Balancing", title: "Algorithms (Round Robin, Least Connections, IP Hash)", description: "Distribution strategies.", answer: { overview: "Methods to decide which server gets the next request.", keyComponents: ["Round Robin", "Hashing"], tradeoffs: ["Simplicity vs. Fairness"] } }, |
| { id: "sd-lb-3", category: "Load Balancing", title: "Health Checks & Failover Handling", description: "Ensuring server availability.", answer: { overview: "LB checks if server is alive before sending traffic.", keyComponents: ["Heartbeats", "Retries"], tradeoffs: ["Detection Speed vs. Overhead"] } } |
| ], |
| "DataStores": [ |
| { id: "sd-ds-1", category: "DataStores", title: "SQL vs NoSQL Databases", description: "Relational vs Non-relational.", answer: { overview: "SQL: Structured, ACID. NoSQL: Flexible, Scalable.", keyComponents: ["Schemas", "Joins"], tradeoffs: ["Strictness vs. Flexibility"] } }, |
| { id: "sd-ds-2", category: "DataStores", title: "Types of NoSQL (Key-Value, Document, Column, Graph)", description: "Different NoSQL models.", answer: { overview: "Redis (KV), MongoDB (Doc), Cassandra (Column), Neo4j (Graph).", keyComponents: ["Data Models", "Use Cases"], tradeoffs: ["Query Power vs. Scale"] } }, |
| { id: "sd-ds-3", category: "DataStores", title: "Database Indexing", description: "Speeding up reads.", answer: { overview: "Data structures to find data faster.", keyComponents: ["B-Trees", "Hash Indexes"], tradeoffs: ["Read Speed vs. Write Speed"] } }, |
| { id: "sd-ds-4", category: "DataStores", title: "Sharding & Partitioning", description: "Splitting data.", answer: { overview: "Horizontal splitting of database rows.", keyComponents: ["Shard Keys", "Consistent Hashing"], tradeoffs: ["Scale vs. Complexity"] } }, |
| { id: "sd-ds-5", category: "DataStores", title: "Replication (Master-Slave, Multi-Master)", description: "Data redundancy.", answer: { overview: "Copying data across multiple servers.", keyComponents: ["Sync vs Async", "Quorum"], tradeoffs: ["Consistency vs. Availability"] } } |
| ], |
| "Practice Problems": [ |
| { id: "sd-pp-1", category: "Practice Problems", title: "Design URL Shortener (like Bitly)", description: "Mapping long URLs to short ones.", answer: { overview: "Use Hashing + KGS + NoSQL. A URL shortener requires a mapping between a long URL and a short key. Key challenges include generating unique keys, handling high read volume, and ensuring low latency.", keyComponents: ["Hashing Service", "Key Generation Service (KGS)", "NoSQL Database (for fast lookups)", "Caching (Redis)", "Load Balancer"], tradeoffs: ["Read-heavy vs Write-heavy optimization", "Centralized vs Distributed Key Generation", "Custom vs Random Aliases"] } }, |
| { id: "sd-pp-2", category: "Practice Problems", title: "Design Instagram Feed", description: "Showing posts from followers.", answer: { overview: "Fan-out on write or read. Use CDNs for images. The system must handle millions of users and high-velocity content updates.", keyComponents: ["Feed Service", "Graph DB (Social Graph)", "Media Storage (S3)", "CDN (Global Distribution)", "Push Notifications"], tradeoffs: ["Latency vs. Freshness", "Pull vs Push Model", "Storage vs Compute"] } }, |
| { id: "sd-pp-3", category: "Practice Problems", title: "Design WhatsApp / Chat System", description: "Real-time messaging.", answer: { overview: "WebSockets for real-time. Message queues for async. Ensuring message delivery and low latency is critical.", keyComponents: ["WebSockets (Gateway)", "Cassandra (Message Store)", "Kafka (Async Processing)", "Push Notification Service", "Presence Service"], tradeoffs: ["Delivery Guarantees (At-least-once vs Exactly-once)", "Speed vs. Reliability", "Encryption Overhead"] } }, |
| { id: "sd-pp-4", category: "Practice Problems", title: "Design YouTube", description: "Video streaming at scale.", answer: { overview: "Transcoding + CDN + Chunked uploads. Handling petabytes of data and concurrent streams.", keyComponents: ["Transcoder (Video Encoding)", "CDN (Edge Servers)", "S3 (Storage)", "Metadata DB (SQL)", "Search Service (ElasticSearch)"], tradeoffs: ["Storage vs. Bandwidth", "Quality vs. Buffering", "Consistency vs. Availability"] } }, |
| { id: "sd-pp-5", category: "Practice Problems", title: "Design Netflix", description: "Content delivery and recommendations.", answer: { overview: "Microservices + Global CDN (Open Connect).", keyComponents: ["CDN", "Microservices"], tradeoffs: ["Personalization vs. Latency"] } }, |
| { id: "sd-pp-6", category: "Practice Problems", title: "Design Twitter/X", description: "Microblogging and timeline.", answer: { overview: "Pull vs Push model for timelines.", keyComponents: ["Redis", "Fan-out"], tradeoffs: ["Celebrity problem handling"] } }, |
| { id: "sd-pp-7", category: "Practice Problems", title: "Design Uber", description: "Real-time location and matching.", answer: { overview: "Geospatial indexing (S2/H3) + Real-time matching.", keyComponents: ["Geo-sharding", "WebSockets"], tradeoffs: ["Accuracy vs. Speed"] } }, |
| { id: "sd-pp-8", category: "Practice Problems", title: "Design Google Drive", description: "File storage and sync.", answer: { overview: "Block-level sync + Metadata DB + Object storage.", keyComponents: ["S3", "Metadata DB"], tradeoffs: ["Sync speed vs. Consistency"] } }, |
| { id: "sd-pp-9", category: "Practice Problems", title: "Design Dropbox", description: "Cloud storage and sync.", answer: { overview: "Similar to GDrive, focus on block-level deduplication.", keyComponents: ["Block Service", "Metadata DB"], tradeoffs: ["Storage cost vs. Sync speed"] } }, |
| { id: "sd-pp-10", category: "Practice Problems", title: "Design Online Payment System", description: "Handling transactions securely.", answer: { overview: "Distributed transactions + Idempotency + Fraud detection.", keyComponents: ["Payment Gateway", "Ledger"], tradeoffs: ["Consistency vs. Availability"] } }, |
| { id: "sd-pp-11", category: "Practice Problems", title: "Design Rate Limiter", description: "Controlling API traffic.", answer: { overview: "Token Bucket or Leaky Bucket algorithms.", keyComponents: ["Redis", "Middleware"], tradeoffs: ["Accuracy vs. Performance"] } }, |
| { id: "sd-pp-12", category: "Practice Problems", title: "Design Notification System", description: "Push, Email, SMS at scale.", answer: { overview: "Pub/Sub + Priority Queues + Third-party integrations.", keyComponents: ["Kafka", "Workers"], tradeoffs: ["Delivery guarantees vs. Latency"] } } |
| ], |
| "Consistency vs Availability": [ |
| { id: "sd-ca-1", category: "Consistency vs Availability", title: "CAP Theorem (Deep Dive)", description: "Understanding the fundamental limits.", answer: { overview: "Detailed look at why you can't have all three in a partition.", keyComponents: ["Network Partition", "PACELC"], tradeoffs: ["Latency vs. Consistency"] } }, |
| { id: "sd-ca-2", category: "Consistency vs Availability", title: "Strong vs Eventual Consistency", description: "Data synchronization models.", answer: { overview: "Strong: Immediate update. Eventual: Updates propagate over time.", keyComponents: ["Quorum", "Replication"], tradeoffs: ["Read Latency vs. Data Freshness"] } } |
| ], |
| "Message Queues": [ |
| { id: "sd-mq-1", category: "Message Queues", title: "What is Message Queue?", description: "Asynchronous communication.", answer: { overview: "Decoupling services using a buffer for messages.", keyComponents: ["Producer", "Consumer", "Broker"], tradeoffs: ["Complexity vs. Scalability"] } }, |
| { id: "sd-mq-2", category: "Message Queues", title: "Kafka vs RabbitMQ vs SQS", description: "Comparing popular MQ tools.", answer: { overview: "Kafka: Log-based, high throughput. RabbitMQ: Smart broker, complex routing.", keyComponents: ["Throughput", "Routing"], tradeoffs: ["Ordering vs. Speed"] } } |
| ], |
| "Caching": [ |
| { id: "sd-c-1", category: "Caching", title: "What is Caching?", description: "Storing data for fast access.", answer: { overview: "Temporary storage to reduce latency and DB load.", keyComponents: ["TTL", "Cache Hit/Miss"], tradeoffs: ["Memory cost vs. Speed"] } }, |
| { id: "sd-c-2", category: "Caching", title: "Cache Eviction Policies (LRU, LFU)", description: "Managing cache space.", answer: { overview: "Deciding which data to remove when cache is full.", keyComponents: ["LRU", "LFU", "FIFO"], tradeoffs: ["Hit rate vs. Overhead"] } } |
| ] |
| }; |
|
|