हर large-scale application एक जैसे fundamental building blocks से बनती है। Interviewers आपसे नई technology invent करने की उम्मीद नहीं रखते - वो देखना चाहते हैं कि आप किसी problem के लिए सही components को select और combine कर सकते हैं या नहीं। इस lesson में वो toolkit cover होगी जो हर design interview में काम आएगी।
Web का core model बहुत simple है: clients requests भेजते हैं, servers उन्हें process करते हैं, और responses वापस आते हैं। लेकिन modern systems में scale, reliability और performance handle करने के लिए इन दोनों endpoints के बीच कई layers जुड़ जाती हैं।
एक typical request का path कुछ ऐसा होता है: client → CDN → load balancer → API gateway → application server → cache → database। हर layer एक specific problem solve करती है, और कब कौन सी layer चाहिए - यह समझना ही strong candidates को average से अलग करता है।
Interviews में हमेशा specifics में जाने से पहले high-level client-server flow sketch करें। इससे structured thinking दिखती है।
एक single server की capacity limited होती है। Load balancers incoming requests को multiple servers में इन strategies से distribute करते हैं:
Load balancers health checks भी perform करते हैं और unhealthy servers को automatically pool से हटा देते हैं। Cloud environments में AWS ALB या Azure Front Door जैसी services यह transparently handle करती हैं।
एक social media feed service को writes से 10 गुना ज़्यादा reads मिलती हैं। कौन सा load balancing approach ensure करेगा कि users consistently same cache-warm server पर पहुँचें?
Caching frequently accessed data को consumer के करीब store करता है। यह कई levels पर exist करता है:
| Layer | उदाहरण | Latency | |-------|---------|---------| | Browser cache | Static assets, API responses | ~0ms | | CDN | Images, CSS, JS files | ~10-50ms | | Application cache | Redis, Memcached | ~1-5ms | | Database cache | Query result cache | ~5-10ms |
Sign in to join the discussion
Cache invalidation computing की सबसे मुश्किल problems में से एक मानी जाती है। Common strategies में TTL (time-to-live), write-through (हर write पर cache update करना), और cache-aside (application खुद cache manage करती है) शामिल हैं।
Phil Karlton की famous quote - "Computer Science में सिर्फ दो hard things हैं: cache invalidation और naming things" - इतनी widely cite होती है कि यह system design interviews में एक rite of passage बन चुकी है।
सही database चुनना सबसे impactful design decisions में से एक है:
SQL databases (PostgreSQL, MySQL) ACID transactions, strong consistency और structured schemas offer करते हैं। जब data में clear relationships हों और complex queries with joins चाहिए, तब ये best हैं।
NoSQL databases कई types में आते हैं:
आप एक ऐसा system design कर रहे हैं जो user profiles store करता है जिसमें frequently changing, semi-structured data है (हर user type के अलग fields)। कौन सा database type सबसे अच्छा fit है?
हर operation को immediate response की ज़रूरत नहीं होती। Message queues (RabbitMQ, Apache Kafka, AWS SQS) producers को consumers से decouple करते हैं, जिससे मिलता है:
Kafka की special बात यह है कि यह सिर्फ queue नहीं बल्कि एक distributed event log है, जो event-driven architectures enable करता है जहाँ multiple consumers independently same stream of events process कर सकते हैं।
| पहलू | Monolith | Microservices | |-------|----------|---------------| | Deployment | Single unit | Independent services | | Scaling | सब कुछ एक साथ scale | Individual services scale | | Complexity | शुरू करना आसान | Operational overhead | | Data | Shared database | Database per service |
Monolith से शुरू करें, ज़रूरत पड़ने पर microservices extract करें। ज़्यादातर interviewers ऐसे candidates को appreciate करते हैं जो यह acknowledge करें कि microservices distributed system complexity (network failures, data consistency, deployment orchestration) लाते हैं और हमेशा सही choice नहीं होते।
Netflix ने कई सालों में monolith से microservices पर migration किया। लेकिन Shopify - जो billions in transactions handle करता है - अभी भी modular monolith चलाता है। किसी company के लिए कौन सा approach बेहतर है, यह किन factors पर depend करता है?
CAP theorem कहता है कि एक distributed system एक साथ तीन में से सिर्फ दो properties guarantee कर सकता है:
चूँकि distributed systems में network partitions inevitable हैं, असली choice CP (consistency over availability) और AP (availability over consistency) के बीच है।
आप एक banking transaction system design कर रहे हैं जहाँ incorrect balances से financial loss हो सकता है। कौन सा CAP trade-off prioritise करना चाहिए?
System design interview में यह structure follow करें:
अपनी daily use की किसी system के बारे में सोचें - Instagram, Uber, या Spotify। क्या आप पहचान सकते हैं कि इस lesson के कौन से building blocks वो use करती होगी? Load balancer कहाँ बैठेगा? क्या cache होगा? कौन सा database type उसके data model पर fit करेगा?
अगला lesson: इन fundamentals को apply करके एक URL shortener scratch से design करेंगे।