GoDasturchi
Designing a URL Shortener at Scale

Designing a URL Shortener at Scale

Katta miqyosda URL Shortener loyihalash

Build a URL Shortener kursida siz uzun havolani QISQA kodga aylantiruvchi, xotirada ishlaydigan xizmatni QURGAN edingiz — bu, bitta uy qurishga o'xshaydi: mustahkam, to'g'ri, lekin BITTA oila uchun. Endi savol: agar bu xizmatga KUNIGA 100 MILLION so'rov kelsa (masalan, mashhur ijtimoiy tarmoqning HAR bir havolasi shu orqali o'tsa) — bino emas, BUTUN SHAHAR qanday qurilishi kerak?

Talab va miqyos: taxmin qilaylik, kuniga 100 million YANGI havola YARATILADI (yozish), va o'qish (redirect — qisqa havoladan asl manzilga YO'NALTIRISH) yozishdan O'NLAB barobar ko'p, aytaylik kuniga 2 milliard. Back-of-the-Envelope Estimation darsidagi usul bilan: 2,000,000,000 / 86,400 ≈ 23,000 QPS o'qish, va 100,000,000 / 86,400 ≈ 1,150 QPS yozish. Bu raqamlar DARHOL ko'rsatadiki — o'qish yuki YOZISHDAN ANCHA ko'p.

Yuqori darajadagi dizayn: o'qish yuki BUNCHALIK katta bo'lganda, HAR bir redirect so'rovini to'g'ridan-to'g'ri bazaga yuborish — bazani TEZDA cho'ktiradi. Yechim — Caching Strategies darsidagi cache-aside: eng ko'p bosilgan qisqa kodlarni (odatda kichik FOIZ havola, KATTA qismi trafikni tashkil qiladi — bu "Pareto taqsimoti" deb ataladi) tez kesh (Redis)da saqlash, shunda 23,000 QPS'ning KATTA qismi bazaga UMUMAN yetib bormaydi.

KomponentVazifasiBog'liq dars
Load balancerKelgan so'rovlarni ko'plab server orasida taqsimlaydiLoad Balancing Algorithms
Kesh (Redis)Ko'p bosiladigan qisqa kodlarni tezkor saqlaydi, bazani yengillatadiCaching Strategies
Baza (shardlangan)Barcha havola-manzil juftliklarini doimiy saqlaydiDatabase Sharding and Partitioning
Rate limiterBitta foydalanuvchi/IP haddan tashqari ko'p havola yaratishining oldini oladiRate Limiting as a System-Level Concern

Chuqur kirish — shard key tanlash: 100 million yangi havola/kun, yillar davomida TRILLIONLAB yozuvga aylanadi — bitta baza YETMAYDI. Shard key sifatida qisqa kodning O'ZINI (yoki uning hash qiymatini) tanlash oqilona — chunki HAR bir redirect so'rovi, aynan shu kod orqali KELADI, va bu QIYMAT so'rovlarni SHARD'lar bo'ylab TEKIS taqsimlaydi (Database Sharding darsidagi "issiq shard"dan qochish tamoyili).

Murosa: bu dizaynda Eventual Consistency YETARLI — agar YANGI yaratilgan havola kesh yoki boshqa replikaga bir necha MILLISEKUND kechikib yetib borsa, hech kim ZARAR ko'rmaydi (Consistency Models darsi). Bu, xuddi shu loyihaning KOD darajasidagi versiyasidan (Build a URL Shortener kursi, bitta xotiradagi map bilan) farqli, ENDI ko'plab server, kesh qatlami, shardlangan baza va rate limiter'dan iborat, TAQSIMLANGAN arxitektura.

Key Takeaway

Key Takeaway:

URL shortener'ni katta miqyosga olib chiqishning kaliti — o'qish yukini (juda katta) kesh bilan yozish yukidan (kichikroq) ajratish, va shard key sifatida qisqa kodning o'zini tanlab, trilliondan ortiq yozuvni tekis taqsimlash. Eventual consistency bu yerda yetarli, chunki yangi havolaning bir necha millisekund kechikib tarqalishi arzon xato.

NEXT UP

Designing a Chat / Messaging System

Designing a URL Shortener at Scale

Katta miqyosda URL Shortener loyihalash

Build a URL Shortener kursida siz uzun havolani QISQA kodga aylantiruvchi, xotirada ishlaydigan xizmatni QURGAN edingiz — bu, bitta uy qurishga o'xshaydi: mustahkam, to'g'ri, lekin BITTA oila uchun. Endi savol: agar bu xizmatga KUNIGA 100 MILLION so'rov kelsa (masalan, mashhur ijtimoiy tarmoqning HAR bir havolasi shu orqali o'tsa) — bino emas, BUTUN SHAHAR qanday qurilishi kerak?

Talab va miqyos: taxmin qilaylik, kuniga 100 million YANGI havola YARATILADI (yozish), va o'qish (redirect — qisqa havoladan asl manzilga YO'NALTIRISH) yozishdan O'NLAB barobar ko'p, aytaylik kuniga 2 milliard. Back-of-the-Envelope Estimation darsidagi usul bilan: 2,000,000,000 / 86,400 ≈ 23,000 QPS o'qish, va 100,000,000 / 86,400 ≈ 1,150 QPS yozish. Bu raqamlar DARHOL ko'rsatadiki — o'qish yuki YOZISHDAN ANCHA ko'p.

Yuqori darajadagi dizayn: o'qish yuki BUNCHALIK katta bo'lganda, HAR bir redirect so'rovini to'g'ridan-to'g'ri bazaga yuborish — bazani TEZDA cho'ktiradi. Yechim — Caching Strategies darsidagi cache-aside: eng ko'p bosilgan qisqa kodlarni (odatda kichik FOIZ havola, KATTA qismi trafikni tashkil qiladi — bu "Pareto taqsimoti" deb ataladi) tez kesh (Redis)da saqlash, shunda 23,000 QPS'ning KATTA qismi bazaga UMUMAN yetib bormaydi.

KomponentVazifasiBog'liq dars
Load balancerKelgan so'rovlarni ko'plab server orasida taqsimlaydiLoad Balancing Algorithms
Kesh (Redis)Ko'p bosiladigan qisqa kodlarni tezkor saqlaydi, bazani yengillatadiCaching Strategies
Baza (shardlangan)Barcha havola-manzil juftliklarini doimiy saqlaydiDatabase Sharding and Partitioning
Rate limiterBitta foydalanuvchi/IP haddan tashqari ko'p havola yaratishining oldini oladiRate Limiting as a System-Level Concern

Chuqur kirish — shard key tanlash: 100 million yangi havola/kun, yillar davomida TRILLIONLAB yozuvga aylanadi — bitta baza YETMAYDI. Shard key sifatida qisqa kodning O'ZINI (yoki uning hash qiymatini) tanlash oqilona — chunki HAR bir redirect so'rovi, aynan shu kod orqali KELADI, va bu QIYMAT so'rovlarni SHARD'lar bo'ylab TEKIS taqsimlaydi (Database Sharding darsidagi "issiq shard"dan qochish tamoyili).

Murosa: bu dizaynda Eventual Consistency YETARLI — agar YANGI yaratilgan havola kesh yoki boshqa replikaga bir necha MILLISEKUND kechikib yetib borsa, hech kim ZARAR ko'rmaydi (Consistency Models darsi). Bu, xuddi shu loyihaning KOD darajasidagi versiyasidan (Build a URL Shortener kursi, bitta xotiradagi map bilan) farqli, ENDI ko'plab server, kesh qatlami, shardlangan baza va rate limiter'dan iborat, TAQSIMLANGAN arxitektura.

Key Takeaway

Key Takeaway:

URL shortener'ni katta miqyosga olib chiqishning kaliti — o'qish yukini (juda katta) kesh bilan yozish yukidan (kichikroq) ajratish, va shard key sifatida qisqa kodning o'zini tanlab, trilliondan ortiq yozuvni tekis taqsimlash. Eventual consistency bu yerda yetarli, chunki yangi havolaning bir necha millisekund kechikib tarqalishi arzon xato.

NEXT UP

Designing a Chat / Messaging System