सिस्टम डिज़ाइन साक्षात्कार गाइड 2026: फ्रेमवर्क, पैटर्न और केस स्टडीज

सिस्टम डिज़ाइन साक्षात्कार शीर्ष तकनीकी कंपनियों में वरिष्ठ इंजीनियरिंग भूमिकाओं के द्वारपाल हैं। वे अस्पष्ट आवश्यकताओं के तहत स्केलेबल, विश्वसनीय सिस्टम डिजाइन करने की आपकी क्षमता का परीक्षण करते हैं। यह मार्गदर्शिका उन रूपरेखाओं, पैटर्नों और वास्तविक उदाहरणों को शामिल करती है जिनकी आपको 2026 में सफलता प्राप्त करने के लिए आवश्यकता है।

साक्षात्कार रूपरेखा

प्रत्येक सिस्टम डिज़ाइन साक्षात्कार एक समान संरचना का अनुसरण करता है। इस 45-मिनट की रूपरेखा का उपयोग करें:

• 1-5 मिनट– आवश्यकताओं को स्पष्ट करें, दायरा परिभाषित करें
• 5-10 मि– अनुमान पैमाना (उपयोगकर्ता, क्यूपीएस, भंडारण)
• 10-20 मिनट– उच्च स्तरीय डिज़ाइन, मुख्य घटक
• 20-35 मि– महत्वपूर्ण घटकों पर गहराई से विचार करें
• 35-45 मि– पैमाना, अड़चनें, समझौता

चरण 1: आवश्यकताएँ स्पष्ट करें

ये प्रश्न पूछने से पहले कभी भी डिज़ाइनिंग शुरू न करें:

• उपयोगकर्ता कौन हैं? उन्हें क्या करने की ज़रूरत है?
• मुख्य विशेषताएं बनाम अच्छा-से-क्या हैं?
• कितने उपयोगकर्ता? पढ़ना-भारी या लिखना-भारी?
• आवश्यक विलंबता क्या है? निरंतरता की आवश्यकता क्या है?
• अपेक्षित डेटा मात्रा क्या है? डेटा कितने समय तक रखा जाता है?

चरण 2: क्षमता का अनुमान

मोटा गणित जो इंजीनियरिंग परिपक्वता का संकेत देता है:

Example: Design Twitter-like feed

Users: 500M total, 100M daily active (DAU)
Tweets: 100M DAU × 5 tweets/day = 500M tweets/day
Reads: 100M DAU × 100 timeline views/day = 10B reads/day

QPS (writes): 500M / 86400 ≈ 5,800 tweets/sec (peak 3x = 17,000)
QPS (reads): 10B / 86400 ≈ 115,000 reads/sec (peak 3x = 345,000)

Storage (tweets):
- 500M tweets/day × 280 bytes = 140 GB/day
- 5 years = 140 × 365 × 5 ≈ 255 TB of tweet data

Media storage: 10% of tweets have images (100MB avg)
50M tweets/day × 100KB thumbnail = 5 TB/day thumbnail storage

कोर डिज़ाइन पैटर्न

1. डेटाबेस चयन

नौकरी के लिए सही डेटाबेस चुनें:

• रिलेशनल (पोस्टग्रेएसक्यूएल, मायएसक्यूएल)– ACID लेनदेन, जटिल प्रश्न, वित्तीय डेटा
• दस्तावेज़ (MongoDB)– लचीली स्कीमा, नेस्टेड डेटा, सामग्री प्रबंधन
• कुंजी-मूल्य (रेडिस, डायनेमोडीबी)– कैशिंग, सत्र भंडारण, O(1) लुकअप
• वाइड-कॉलम (कैसेंड्रा, HBase)– समय-श्रृंखला, बड़े पैमाने पर लेखन-भारी
• ग्राफ़ (Neo4j)– सामाजिक ग्राफ़, अनुशंसा इंजन
• खोजें (इलास्टिक्स खोज)– पूर्ण-पाठ खोज, लॉग विश्लेषण

2. कैशिंग रणनीति

Cache-Aside (Lazy Loading):
  App → cache miss → DB → write to cache → return

Write-Through:
  App → write to cache AND DB simultaneously

Write-Back (Write-Behind):
  App → write to cache → async write to DB (faster, risk data loss)

Read-Through:
  Cache handles DB fetching automatically (used by Redis+Memcached)

Cache Eviction Policies:
  LRU  — Least Recently Used (most common)
  LFU  — Least Frequently Used
  TTL  — Time-To-Live expiry

3. भार संतुलन

सर्वरों पर ट्रैफ़िक वितरित करें:

• राउंड रोबिन– समान वितरण, सरल
• सबसे कम कनेक्शन– सबसे कम सक्रिय कनेक्शन वाले सर्वर का मार्ग
• आईपी ​​हैश— क्लाइंट आईपी पर आधारित कठिन सत्र
• भारित– सर्वर क्षमता के आधार पर वितरित करें

उपकरण: AWS ALB, Nginx, HAProxy, Envoy, Cloudflare

4. डेटाबेस स्केलिंग

Vertical Scaling: Bigger machine (CPU, RAM, SSD)
  Pros: Simple, no code changes
  Cons: Limits, single point of failure, expensive

Read Replicas: Primary handles writes, replicas handle reads
  Pros: Read scalability, disaster recovery
  Cons: Replication lag (eventual consistency)

Sharding (Horizontal Partitioning):
  Split data across multiple DBs by key

  Hash-based: shard = hash(user_id) % num_shards
    Pros: Even distribution
    Cons: Hard to add shards (resharding)

  Range-based: shard by date range or ID range
    Pros: Range queries efficient, easy to add new shards
    Cons: Hot spots (most recent shard gets all writes)

  Directory-based: lookup table maps keys to shards
    Pros: Flexible
    Cons: Lookup overhead, single point of failure

केस स्टडी: डिज़ाइन यूआरएल शॉर्टनर (बिट.ली)

आवश्यकताएं

कार्यात्मक: यूआरएल छोटा करें, विज़िट पर रीडायरेक्ट करें, कस्टम उपनाम, समाप्ति
गैर-कार्यात्मक: 100 एमएस पढ़ने की विलंबता, 100 एम यूआरएल/दिन लिखना, 10 बी पढ़ने/दिन

स्केल अनुमान

लिखता है: 100एम/दिन = 1,200 क्यूपीएस (उच्चतम 3,600)
पढ़ता है: 10बी/दिन = 115,000 क्यूपीएस (उच्चतम 345,000) –पढ़ें-भारी 100:1
भंडारण: 100एम × 500 बाइट्स = 50 जीबी/दिन × 5 वर्ष = ~90 टीबी

उच्च स्तरीय डिज़ाइन

Client → Load Balancer → Web Servers → Cache (Redis)
                                          ↓ cache miss
                                       Database (PostgreSQL + replicas)

URL Shortening API:
  POST /api/shorten
  { "url": "https://very-long-url.com/path", "alias": "mylink", "expires_at": "2027-01-01" }
  → { "short_url": "https://bit.ly/abc123" }

Redirect API:
  GET /{short_code}
  → 301/302 redirect to original URL

Key Generation:
  Option 1: Base62 hash of MD5(url) — take first 7 chars
  Option 2: Counter + Base62 encode (guaranteed unique)
  Option 3: Pre-generate keys in KGS (Key Generation Service)

डेटाबेस स्कीमा

CREATE TABLE urls (
  id           BIGSERIAL PRIMARY KEY,
  short_code   VARCHAR(10) UNIQUE NOT NULL,
  original_url TEXT NOT NULL,
  user_id      BIGINT,
  created_at   TIMESTAMP DEFAULT NOW(),
  expires_at   TIMESTAMP,
  click_count  BIGINT DEFAULT 0
);

CREATE INDEX idx_short_code ON urls(short_code);
CREATE INDEX idx_user_id ON urls(user_id);

केस स्टडी: एक चैट सिस्टम डिज़ाइन करें (व्हाट्सएप)

प्रमुख चुनौतियाँ

• वास्तविक समय पर डिलीवरी– लगातार कनेक्शन के लिए वेबसॉकेट
• संदेश आदेश देना– प्रति वार्तालाप अनुक्रम संख्याएँ
• ऑफलाइन डिलीवरी– उपयोगकर्ता के पुनः कनेक्ट होने तक संदेशों को संग्रहीत करें
• रसीदें पढ़ें– वितरित/पढ़ने की स्थिति
• समूह बातचीत– एकाधिक उपयोगकर्ताओं के लिए फैन-आउट

Architecture:

Client ←→ WebSocket Gateway (stateful) ←→ Message Service
                                              ↓
                                    Message Queue (Kafka)
                                              ↓
                                    Message Store (Cassandra)
                                    - Partitioned by conversation_id
                                    - Ordered by timestamp within partition

Message Flow:
1. User A sends message → WebSocket Gateway (Server A)
2. Gateway publishes to Kafka topic
3. Message Service writes to Cassandra
4. User B's WebSocket Gateway subscribes and delivers
5. If User B offline → push notification via FCM/APNs

Schema (Cassandra - wide column):
  messages_by_conversation
    conversation_id (partition key)
    message_id (clustering key, time-ordered)
    sender_id, content, message_type, created_at

जानने योग्य प्रमुख ट्रेड-ऑफ़

• एसक्यूएल बनाम नोएसक्यूएल– एसीआईडी ​​बनाम स्केल, स्कीमा बनाम लचीलापन
• संगति बनाम उपलब्धता– सीएपी प्रमेय (सामाजिक के लिए एपी, बैंकिंग के लिए सीपी को प्राथमिकता दें)
• खींच बनाम धक्का– पढ़ने पर फैन-आउट बनाम फ़ीड के लिए लिखने पर फैन-आउट
• मोनोलिथ बनाम माइक्रोसर्विसेज– सरलता बनाम स्केलेबिलिटी/टीम स्वायत्तता
• सिंक्रोनस बनाम एसिंक– विलंबता बनाम थ्रूपुट/लचीलापन
• मजबूत बनाम अंतिम संगति– शुद्धता बनाम उपलब्धता

सामान्य सिस्टम डिज़ाइन विषय (2026)

1. यूआरएल शॉर्टनर
2. ट्विटर/सामाजिक फ़ीड
3. व्हाट्सएप/मैसेंजर
4. इंस्टाग्राम/फोटो शेयरिंग
5. यूट्यूब/वीडियो स्ट्रीमिंग
6. उबर/राइड शेयरिंग
7. एयरबीएनबी/बुकिंग प्रणाली
8. गूगल खोज
9. दर सीमक
10. वितरित कैश (रेडिस)
11. अधिसूचना प्रणाली
12. वेब क्रॉलर
13. मेट्रिक्स/निगरानी (प्रोमेथियस)
14. वितरित संदेश कतार (काफ्का)

सिस्टम डिज़ाइन साक्षात्कार स्पष्ट संचार, संरचित सोच और सही उत्तरों के मुकाबले व्यापार-बंद के बारे में जागरूकता को पुरस्कृत करते हैं। प्रत्येक सप्ताह शुरुआत से 2-3 सिस्टम डिज़ाइन करने का अभ्यास करें, और एक भी बॉक्स बनाने से पहले हमेशा स्पष्ट प्रश्न पूछें।