Sistem Tasarımı Diyagramı Örneği: Gereksinimlerden Diyagrama Bir URL Kısaltıcı

Bir sistem tasarımı mülakatında ya da bir tasarım dokümanında akıl yürütmenin görünür hale geldiği yer diyagramdır. "Önbellek" etiketli bir kutu çizmek kolaydır; diyagramı okumaya değer kılan, o kutunun neden orada olduğunu, trafiğin ne kadarını karşıladığını ve önbellek soğukken ne olduğunu göstermektir.

Bu rehber klasik bir alıştırmayı, bir URL kısaltıcıyı, gereksinimlerden bitmiş bir sistem tasarımı diyagramına kadar adım adım ele alıyor. Asıl mesele kısaltıcının kendisi değil, yöntem: önce gereksinimler ve sayılar, sonra API ve veri, en son kutular; her karar da herkesin görebileceği bir yere yazılır.

Adım 1: Gereksinimler

İşlevsel:

Uzun bir URL için kısa link oluşturma; isteğe bağlı olarak özel bir takma ad ve son geçerlilik tarihiyle.
Kısa linki uzun URL'sine yönlendirme.
Link başına tıklamaları sayma.

İşlevsel olmayan:

Yönlendirmeler hızlı ve yüksek erişilebilir olmalı; link oluşturma daha fazla gecikmeyi tolere edebilir.
Sistem okuma ağırlıklıdır: linkler bir kez oluşturulur ve defalarca tıklanır.
Kısa kodlar kolayca numaralandırılamamalı.

Adım 2: Kaba hesaplar

Ayda 100 milyon yeni link ve oluşturulan her link için 100 yönlendirme varsayın:

Büyüklük	Tahmin
Yazma	100M / ayda 2,6M saniye ≈ ortalama saniyede 40
Okuma	100 × 40 ≈ saniyede 4.000 yönlendirme; 10× zirvelere göre planlayın, yani saniyede 40.000
5 yıl sonra link sayısı	100M × 12 × 5 = 6 milyar
Depolama	6 milyar × ~500 bayt ≈ 3 TB, replikalar hariç
Kod uzunluğu	7 karakterlik base62, 62⁷ ≈ 3,5 trilyon kod verir

Sayılar tasarımı şimdiden şekillendiriyor: okumalar baskın olduğu için okuma yoluna önbellek eklenir; 3 TB sonsuza kadar tek bir küçük veritabanında kalmayacağı için veri modelinin sorunsuzca shard'lanabilmesi gerekir; 7 karakter de bolca yer bırakır.

Adım 3: API

POST /api/links
{ "url": "https://example.com/a/very/long/path", "alias": "launch", "expiresAt": "2027-01-01" }
→ 201 { "code": "launch", "shortUrl": "https://s.example/launch" }

GET /{code}
→ 302 Location: https://example.com/a/very/long/path

Bir karar diyagramda kendine bir satırı hak ediyor: 301 mi, 302 mi? 301 kalıcıdır; tarayıcılar onu önbelleğe alır ve tekrarlanan ziyaretler size hiç ulaşmaz. Bu trafikten tasarruf sağlar ama tıklama sayılarını kaybettirir. 302 ise her tıklamayı yönlendirme servisinden geçirir; analitiğin ihtiyaç duyduğu da budur. Bu tasarım 302 kullanıyor.

Adım 4: Veri modeli ve ID'ler

Ana tablo basittir: code (birincil anahtar), long_url, owner_id, created_at, expires_at. Her okuma code ile yapılan bir aramadır; bu yüzden anahtar-değer deposu da birincil anahtarlı ilişkisel bir veritabanı da iş görür ve code değerinin hash'ine göre shard'lamak yükü eşit dağıtır.

Kod üretmek işin ilginç kısmı:

Yaklaşım	Artıları	Eksileri
Sayaç + base62	Çakışma yok	Ardışık kodlar kolayca numaralandırılır; koordinasyon gerekir
Rastgele 7 karakter	Tahmin etmesi zor, koordinasyon gerekmez	Eklemede çakışma kontrolü şart
URL'nin hash'i	Aynı URL aynı kodu alır	Kırpınca çakışmalar; takma adlar ayrıca ele alınmalı

Burada yazma API'si, bir ID aralığı ayırıcısından ID aralıkları rezerve eder (örneğin her seferinde bir milyon) ve her ID'yi base62 ile kodlamadan önce tersine çevrilebilir bir permütasyonla karıştırır. Böylece kodlar çakışma kontrolüne gerek kalmadan benzersiz olur ve dışarıdan bakan biri için ardışık görünmez.

Adım 5: Diyagram

Gereksinimleri farklı olan yolları ayırın. Yazma yolu düşük hacimlidir ve doğru olmalıdır; okuma yolu yüksek hacimlidir ve hızlı olmalıdır; analitik geriden gelebilir.

Bir URL kısaltıcının sistem tasarımı diyagramı: yazma istekleri, bir ayırıcıdan ID'leri rezerve edip linkleri kaydeden bir yazma API'sine gider; yönlendirmeler önce Redis'i, ardından link veritabanını okur ve tıklama olaylarını Kafka üzerinden analitiğe gönderir. — Bu rehberdeki URL kısaltıcı: ID ayırıcıdan geçen bir yazma yolu, Redis önbelleğinden yanıt veren bir okuma yolu, asenkron tıklama analitiği ve tasarımı belirleyen tahminler.

Nasıl okunur:

Yazma yolu (üstte). Yük dengeleyici POST /api/links isteğini yazma API'sine yönlendirir; API, rezerve ettiği aralıktan bir ID alır, kodlar ve linki veritabanına yazar.
Okuma yolu (ortada). GET /{code} yönlendirme servisine gider; servis önce Redis'e bakar. Sık erişilen veri kümesi belleğe sığdığı sürece yönlendirmelerin çoğu veritabanına hiç dokunmaz. Önbellekte bulamazsa veritabanından okur ve önbelleği doldurur.
Analitik (altta). Her yönlendirme Kafka'ya bir tıklama olayı gönderir; analitik worker'ları sayıları toplayıp analitik deposuna yazar. Yönlendirme analitiği asla beklemez.

Akıl yürütmeyi gösterecek şekilde çizin

Sayıları kenarlara yazın. Yazma kenarındaki 40/s ve okuma kenarındaki 4k/s, peak 40k/s, önbelleği herhangi bir etiketten daha iyi açıklar.
Varsayımları kutuların yanına yazın. "Önbellek isabet oranı hedefi %90", "Analitik için 302", "ID'ler 1M'lik aralıklarla rezerve edilir".
Senkron ve asenkronu ayırın. İstek yolu için düz, tıklama olayları için kesikli kenarlar kullanın.
Bir şey bozulduğunda ne olduğunu gösterin. Redis çökerse yönlendirmeler daha yüksek gecikmeyle veritabanına döner; bunu diyagrama yazın.
Tahminleri tuvalde tutun. Diyagramın yanındaki küçük bir sayı tablosu onu bir tasarım dokümanına dönüştürür.

Hazırlanmaya değer derinlemesine konular

Önbellekleme. Popüler linkler uzun kuyruklu bir dağılım izler; bu yüzden ölçülü bir TTL'e sahip bir LRU önbellek trafiğin çoğunu karşılar. Silme ve süre dolumunda önbelleği geçersiz kılın.
Veritabanını ölçekleme. Okuma replikaları burada önbellek kadar fayda sağlamaz; koda göre shard'lama, yazmaların ve depolamanın dengeli büyümesini sağlar.
Süre dolumu. Devasa bir silme işi yerine okuma sırasında expires_at alanını kontrol edin ve arka planda temizleyin.
Kötüye kullanım. Link oluşturmaya kullanıcı başına hız sınırı koyun ve hedef URL'leri kötü amaçlı yazılım listelerine karşı kontrol edin.

Archboard'da oluşturun

Google ya da GitHub ile giriş yapın ve bir diyagram oluşturun.
Kullanıcılar için Ağ paketinden bir İnternet düğümü, yük dengeleyici için de Bulut paketinden bir Bulut yük dengeleyici ekleyin.
Yazma API'sini, yönlendirme servisini, ID ayırıcıyı ve analitik worker'larını C4 Modeli paketinden Konteyner düğümleri olarak ekleyin; programlama dilini Teknoloji alanına yazın.
Veri paketinden önbellek için bir Redis, link veritabanı için bir Postgres, tıklama olayları için bir Konu ve analitik için bir Veri ambarı ekleyin.
Kenarları işlem ve hız bilgisiyle etiketleyin, tıklama olaylarını kesikli çizgiyle gösterin ve tahminleri Temel paketinden bir Markdown bloğuna koyun.

Örnek, tahminleri içeren Markdown bloğu dahil 11 diyagram düğümü kullanıyor ve Free planın sınırları içinde kalıyor. Her mimari diyagramın arkasındaki genel yöntem için yazılım mimarisi diyagramı nasıl çizilir yazısına bakın.

SSS

Bir mülakatta sistem tasarımı diyagramı ne kadar ayrıntılı olmalı? Okuma ve yazma yollarını, veri deposunu, önbelleği ve asenkron bir parçayı gösterecek kadar. Yalnızca mülakatı yapan kişinin sorduğu yerlerde derinleşin.

Link tablosu için SQL mi, NoSQL mi? Birincil anahtarla arama için ikisi de olur. Nasıl shard'lamayı planladığınıza ve ekibinizin neyi iyi işlettiğine göre seçin; gerekçeyi de diyagrama yazın.

CDN çizmeli miyim? Yalnızca yönlendirmeleri edge'de önbelleğe alıyorsanız. 302 ve tıklama sayımıyla edge önbelleklemenin faydası sınırlıdır, bu yüzden birçok tasarım CDN'i dışarıda bırakır.

Neden her yerde 301 değil? 301 trafikten tasarruf ettirir ama tarayıcılar size sormayı bırakır; böylece tıklama verisini kaybedersiniz ve tekrar gelen ziyaretçiler için hedefi değiştiremezsiniz.

Sayılar nereye yazılır? Tuvale, diyagramın yanına; böylece tasarımı inceleyen herkes kutuların arkasındaki varsayımları kontrol edebilir.

Ücretsiz başlayın — tek kullanıcı, kredi kartı gerekmez.