मुफ़्त पूरी गाइड
10 करोड़ daily active users के लिए एक scalable URL shortener डिज़ाइन करें। redirects, custom aliases, analytics, caching, और consistency trade-offs को कवर करें।
Interview की लय संक्षिप्त रहती है, ताकि page असली design निर्णयों पर ध्यान लगा सके.
सिर्फ requirements मत बताइए — पूछिए। हर card एक design constraint को उस clarification सवाल से जोड़ता है जो आप architecture बनाने से पहले बोल सकते हैं.
01क्या users को custom alias चुनने में सक्षम होना चाहिए, या system-generated short code काफ़ी है?
Users एक long URL submit करके एक unique short link वापस पा सकते हैं — default रूप से system-generated base62 code (letters + digits), custom alias एक optional extra के रूप में।
02क्या links हमेशा के लिए रहते हैं, या हमें expiration और cleanup चाहिए?
Users एक optional expiration set कर सकते हैं; expired link redirect करना बंद कर देता है और उसका code बाद में retire किया जा सकता है।
03क्या redirect ही core flow है — click पर कुछ और भी होना ज़रूरी है?
जो कोई एक short link खोलता है उसे original URL पर redirect किया जाता है — अब तक का सबसे बार-बार होने वाला operation। हर click भी record होनी चाहिए, और recording कभी redirect में देरी न करे।
04क्या marketing campaigns को bulk creation चाहिए — एक call में हज़ारों links?
Batch creation support कीजिए: एक campaign एक request में हज़ारों links बना देता है।
05क्या किसी link को creation के बाद नए destination पर retarget किया जा सकता है?
Links बनने के बाद बदलते नहीं। किसी नई destination पर retargeting एक वैकल्पिक extra है। Retarget के बाद, visitors को नई destination पर उतरना ही चाहिए, कभी पुरानी पर नहीं।
06किसी link का मालिक कौन है — क्या creators अपने links को list और deactivate कर सकते हैं?
Links अपने creator के होते हैं: list, deactivate, और retire — एक deactivated link को seconds के भीतर redirect करना बंद करना होगा।
Scope से बाहरAnalytics dashboard — केवल async click-event emission scope में रहता है · User accounts, auth, और link-management UI · Spam और malicious-URL scanning
01मुझे कौन-सा read/write ratio मानना चाहिए — क्या यह heavily read-skewed है?
Read-heavy: एक आम दिन में करीब 100M लोग एक short link follow करते हैं, बनाम करीब 1M नए links बनते हैं। यानी कम-से-कम 100:1 redirects बनाम creates। Marketing-heavy deployments 1000:1 के करीब चलते हैं, इसलिए यह पूछना ज़रूरी है कि यह कौन-सा है।
02Redirect user को कितना तेज़ महसूस होना चाहिए?
Redirect p95 100 ms से नीचे — short-link hop click करने वाले को invisible महसूस हो।
03क्या एक बिल्कुल नया link हर जगह तुरंत resolve होना चाहिए, या थोड़ी देरी ठीक है?
Consistency से ऊपर availability: redirects का target 99.99%। एक अभी-अभी बना link हर cache और replica तक पहुँचने में कुछ सेकंड ले सकता है (eventual consistency स्वीकार्य)।
04Code space और storage को कुल कितने links के लिए plan करना चाहिए?
~1B links की योजना बनाओ। एक 7-char base62 code 62^7 ≈ 3.5 trillion संभव codes देता है, ढेर सारी गुंजाइश। प्रति row ~1 KB पर, कुल storage करीब 1 TB रहता है, short code से shardable।
05क्या दो links कभी एक ही code साझा कर सकते हैं — और क्या कोई private codes का अनुमान लगा सकता है?
Short codes globally unique होने चाहिए — कोई collisions नहीं, कभी नहीं। Private links के लिए, codes guessable न हों: एक predictable sequence एक अजनबी को private URLs एक-एक करके enumerate करने देगा।
असली interview एक साफ list से कहीं गहरा probe करते हैं. ये scope सवाल उन्हें अलग करते हैं जो problem को कुरेदते हैं बनाम जो रटते हैं.
हर estimate को एक दबाव मानिए जो किसी component को justify करता है: cache, queue, partition, replica, worker pool, या fallback path.
Redirect read QPS
100M daily users (ऊपर वाली read-heavy sizing) × प्रति दिन हर एक ~1 redirect = 100M redirects/day100,000,000 redirects ÷ दिन में 86,400 s ≈ 1,160 QPS औसत · viral bursts ×5-10 ≈ 5-10K QPS peak
Cache + CDN को peak absorb करना ही होगा — database कभी redirect hot path को serve नहीं करता।
Create write QPS
~1M नए links प्रति दिन1,000,000 ÷ 86,400 s ≈ 12 writes/s
Writes मामूली हैं, इसलिए कोई write scaling ज़रूरी नहीं। एकमात्र write-side risk row inserts नहीं, code allocation पर झगड़ा है।
Total storage
1B links × ~1 KB प्रति row (code, long URL, owner, timestamps, TTL)10⁹ × 1 KB ≈ 1 TB
एक sharded store में आराम से समा जाता है; short_code index ही असली working set है।
Code space
7-character base62 codes (प्रति position 62 characters)62⁷ ≈ 3.5 × 10¹² codes बनाम ज़रूरी 10⁹ links → ~3,500× headroom
Codes कभी ख़त्म नहीं होते — असली जोखिम predictability (enumerable codes) है, exhaustion नहीं।
Cache size
मान लें ~20% links ~80% reads serve करते हैं (Pareto)20% × 1 TB ≈ 200 GB
एक मामूली Redis cluster पर संभव। सबसे गरम viral links CDN edge पर भी बैठते हैं।
निर्णय उदाहरण
संख्याएँ एक ही ओर इशारा करती हैं। Reads writes से करीब 100 गुना ज़्यादा हैं, और peak पर 5-10K redirects प्रति सेकंड, हर एक को 100 ms से कम में जवाब देना है। इसलिए redirect ही एकमात्र path है जिसे optimize करना सार्थक है।
Redirects का जवाब पहले एक cache से दो — Redis, प्लस सबसे गरम links के लिए CDN। इस तरह database कभी hot path में नहीं आता। Links बनाने के लिए, एक छोटा key service हर API server को पहले से बने unique codes का एक batch देता है, इसलिए एक create किसी साझा counter पर कभी नहीं झगड़ता। Clicks को एक stream पर एक event डालकर गिना जाता है। Redirect analytics का इंतज़ार कभी नहीं करता।
जो मैं नहीं करूँगा: code बनाने के लिए long URL को hash करना और जब भी दो URLs collide करें तब retry करना। Load के तहत ये retries जमा हो जाते हैं और link बनाना एक lottery बन जाता है। पहले से बने unique codes बाँटना collisions को असंभव बना देता है, न कि केवल असंभावित।
अगर सटीक per-click analytics एक must-have बन जाए, तो मैं 301 से 302 redirects पर switch करूँगा। तब browsers hop को cache करना बंद कर देते हैं, इसलिए हर click मेरे servers तक पहुँचता है और गिना जाता है। मैं थोड़ी extra latency स्वीकार करता हूँ।
पहले एक पूरी तस्वीर, फिर हर path को अपना अलग diagram — write path और read path अलग traffic ढोते हैं और अलग components justify करते हैं.
पूरी तस्वीर
सरल version से शुरू करें: एक ही चित्र, हर component और relation। Dashed = asynchronous, hot path से अलग। एक cache miss database पर fall back करता है और cache को फिर से भर देता है।
Path 1
KGS पहले से generate किए गए unique code ranges बाँटता है, इसलिए creates कभी collide नहीं करते और किसी shared counter पर कभी block नहीं होते।
Path 2
Cache miss database पर fall back करता है और cache को फिर से भरता है; click events off-path analytics stream पर जाते हैं।
optimize करने से पहले contract को inspectable बनाइए: endpoints, entities, ownership, retries, और state.
POST/urls
req{ long_url, custom_alias?, expires_at? }
res200 { short_url, expires_at } · 409 alias पहले से लिया गया · 400 अमान्य URL
(owner, long_url) के लिए idempotent: दोबारा submit करने पर नया code बनाने के बजाय मौजूदा short_url लौटाया जाता है।
GET/{short_code}
res301/302 + Location: long_url · 404 अज्ञात code · 410 expired
301 browsers को redirect cache करने देता है (कम origin hits, click analytics खो देता है); 302 हर click को आपके servers से भेजता है (analytics बचाता है, एक hop जोड़ता है)। यह चुनाव analytics requirement पर टिका है — इसे ज़ोर से कहें।
Core entities
ShortLinkshort_code (PK) · long_url · owner_id · created_at · expires_at · is_active
short_code के अनुसार shard करें ताकि एक redirect ठीक एक ही partition पर पड़े; एक optional inverted index long_url → short_code, create-time dedup सक्षम करता है।
Useruser_id (PK) · email · created_at
interview के आखिरी एक-तिहाई के लिए एक lane चुनें. हर lane आपको topic, वह interviewer सवाल जिसका जवाब देना है, और बचने वाला failure mode देती है.
आप कैसे guarantee करते हैं कि दो links को कभी एक ही code न मिले — counter + base62, या hashing? वही क्यों?
Codes पहले से बनाओ, hash मत करो। एक अलग service unique codes पहले ही तैयार कर देती है और हर API server को उसका अपना block दे देती है, बांटने के लिए। दो servers एक ही code नहीं चुन सकते, और किसी को पहले database check करने की ज़रूरत नहीं — बड़े campaign के दौरान भी नहीं। Hashing से clashes बस दुर्लभ होते हैं, और हर clash एक retry मांगता है — ठीक तब जब load सबसे ज़्यादा हो।
URL को hash करना और उम्मीद करना कि collisions दुर्लभ हैं, बिना uniqueness guarantee समझाए।
एक redirect को end to end चलाएँ: cache कहाँ hit होता है, miss पर क्या होता है, और database वास्तव में कब touch होता है?
Code पहले Redis से पढ़ो। एक cache hit कुछ ही milliseconds में जवाब देता है और database को कभी छूता नहीं; एक miss उसे एक बार पढ़ता है, फिर cache दोबारा भर देता है। सबसे hot links CDN edge पर भी बैठते हैं। जब कोई link बंद या retarget होता है, TTL का इंतज़ार मत करो — उसे Redis से तुरंत delete करो और CDN copy purge करो, ताकि बदलाव seconds में लागू हो।
हर redirect पर database पढ़ना — hot path cache-first होना चाहिए।
आप कौन-सा redirect status लौटाते हैं, और वह चुनाव browser caching और आपके click data पर क्या असर डालता है?
यहाँ 302 इस्तेमाल करो, क्योंकि हमें हर click गिननी है। 302 browser को हर बार server से पूछने पर मजबूर करता है, तो हर click दर्ज होती है — कीमत बस एक extra hop। 301 browser को redirect हमेशा के लिए cache करने देता है: तेज़, पर repeat clicks अदृश्य हो जाती हैं। चूंकि clicks गिनना एक requirement है, 302 जीतता है।
मनमाने ढंग से एक चुनना — यह चुनाव ही analytics निर्णय है।
आप latency जोड़े बिना 100M DAU के लिए clicks कैसे record करते हैं, और अगर analytics pipeline पीछे रह जाए तो क्या होता है?
Redirect एक click event को Kafka जैसे durable stream पर डालता है और तुरंत लौट आता है — गिनती बाद में होती है, एक तरफ़। अगर वह pipeline पीछे रह जाए, तो counts कुछ देर के लिए stale हो जाते हैं, पर redirects कभी धीमे नहीं होते। Stale numbers एक स्वीकार्य trade हैं; धीमे redirects नहीं।
Redirect के अंदर analytics को synchronously लिखना।
एक ही link अचानक सारे traffic का 10% ले लेता है — पहले क्या टूटता है, और cache तथा CDN उसे कैसे absorb करते हैं?
एक अकेला viral link उस एक cache shard को overload कर देता है जो उसे रखता है, database को भनक लगने से बहुत पहले। उसे CDN edge से short TTL के साथ serve करो, ताकि लाखों hits हम तक पहुँचने से पहले ही सोख लिए जाएँ। API servers उसे local memory में backup के तौर पर भी रख सकते हैं। एक link कितना भी spike करे, origin traffic flat रहता है।
यह मान लेना कि traffic समान रूप से फैला है — hot keys ही असली load हैं।
लघु लिंक सेवा को ज़ोर से समझाइए और अपनी व्याख्या पर AI scoring पाइए.