Sistem Tasarımı Mülakatı: Adım Adım Çalışma Yöntemi

Sistem Tasarımı Mülakatı Nedir, Ne Değildir?

Sistem tasarımı mülakatı, tek doğru cevabı olan bir sınav değil; belirsizlik altında teknik karar verebilme becerinin tartışıldığı bir oturumdur. Orta seviye bir geliştirici için amaç, ezberlenmiş mimari şablonları sıralamak değil; gereksinimleri netleştirmek, kısıtları sayısallaştırmak ve önerdiğin tasarımın neden o kısıtlar altında makul olduğunu savunmaktır.

Bu rehber, dile ve teknoloji yığınına bağlı olmayan bir çalışma yöntemi önerir. Örnekler kavramsaldır; belirli bir ürün sürümüne veya ölçüm sonucuna dayanmaz.

Önkoşullar: Temel veri yapıları ve algoritma bilgisi, HTTP ve TCP/IP düzeyinde ağ farkındalığı, ilişkisel veritabanı ve indeksleme deneyimi, en az bir sunucu tarafı dilde üretim kodu yazmış olmak. Dağıtık sistemlerde üretim deneyimi zorunlu değildir; ancak kavramları isimleriyle bilmen beklenir.

Mülakatın Beklediği Düşünme Biçimi

Görüşmeci genellikle şu sinyalleri arar:

• Belirsizliği yönetme: Soruyu olduğu gibi kabul etmek yerine kapsamı daraltman.
• Sayısallaştırma: "Çok kullanıcı" yerine okuma/yazma oranı, veri hacmi ve gecikme hedefi gibi somut büyüklükler kullanman.
• Ödünleşim (trade-off) farkındalığı: Bir seçeneği överken bedelini de söylemen.
• Derinleşme: Yüzeysel kalmak yerine seçtiğin bir bileşeni sorgulandığında detaylandırabilmen.
• İletişim: Sessizce düşünmek yerine varsayımlarını yüksek sesle paylaşman.

Adım Adım Çalışma Yöntemi

1. Gereksinimleri netleştir

Önce işlevsel gereksinimleri (sistem ne yapacak) ve işlevsel olmayan gereksinimleri (ne kadar hızlı, ne kadar dayanıklı, ne kadar tutarlı) ayır. Sorularda tipik olarak şunları netleştirmen beklenir:

• Kullanıcı sayısı ve aktif kullanıcı oranı
• Okuma/yazma oranı
• Veri boyutu ve büyüme hızı
• Kabul edilebilir gecikme
• Tutarlılık gereksinimi (güçlü mü, nihai mi)
• Erişilebilirlik hedefi

Bu maddeleri tahminle değil, soruya sorarak veya açık varsayım belirterek doldur. Varsayım yapıyorsan "şu an şu kabulü yapıyorum, uygun mu?" diye sor.

2. Kaba hesaplama yap

Tasarımı savunmak için büyüklük mertebesi yeterlidir. Örneğin günlük yazma sayısını saniyeye çevirmek için gün içindeki saniye sayısına bölmek yeterli bir yaklaşımdır; ancak trafiğin gün içinde eşit dağılmadığını varsayarak bir tepe çarpanı eklemeyi düşün. Depolama için kayıt başına boyutu toplam kayıt sayısıyla çarp. Bu hesapların amacı kesin sonuç değil, hangi bileşenin ölçek darboğazı olacağını görmektir.

3. Yüksek seviyeli taslağı çiz

Tipik bir akış şu katmanlardan oluşur:

• İstemci
• Yük dengeleyici / API ağ geçidi
• Uygulama servisleri (durumsuz tutulmaya çalışılır)
• Önbellek katmanı
• Veri deposu (ilişkisel, anahtar-değer, arama indeksi vb.)
• Kuyruk / olay akışı (asenkron işler için)
• İzleme ve günlükleme

Bu katmanları çizerken her bileşenin neden orada olduğunu bir cümleyle açıkla. Gerekçesini söyleyemediğin bileşeni şemaya eklemek puan kaybettirir.

4. Veri modelini ve erişim desenini belirle

Önce erişim desenlerini yaz, sonra şemayı seç. Hangi sorgular sık, hangileri seyrek? Hangi alanlar üzerinden filtreleme yapılıyor? Bu soruların cevabı, ilişkisel mi yoksa anahtar-değer mi tercih edeceğini belirler. İlişkisel veritabanı seçiyorsan hangi alanların indeksleneceğini ve bunun yazma maliyetini nasıl etkilediğini belirt.

5. Ölçekleme ve dayanıklılık kararlarını gerekçelendir

Burada tipik konular şunlardır:

• Yatay ölçekleme: Durumsuz servisler ve yük dengeleme.
• Önbellekleme: Neyi, nerede, hangi geçersiz kılma stratejisiyle önbelleğe alacağın.
• Çoğaltma (replication): Okuma yükünü dağıtmak mı, yoksa felaket kurtarma mı hedeflediğin.
• Parçalama (sharding): Anahtar seçimi, sıcak bölüm (hot partition) riski ve yeniden dengeleme.
• Tutarlılık: Kullanıcıya ne zaman "yazıldı" diyeceğin.
• Kuyruk kullanımı: Anlık yükü emmek ve yeniden deneme için.

Her kararın bedelini söyle: önbellek tutarlılık riski getirir, çoğaltma gecikmeli okuma yaratabilir, parçalama işlemleri karmaşıklaştırır.

6. Darboğazı ve başarısızlığı konuş

Tasarımı bitirdikten sonra "bu sistem nerede kırılır?" sorusunu kendin sor. Tek bir bileşenin çökmesi ne olur? Kuyruk dolarsa ne olur? Önbellek soğuksa veritabanı ne kadar yük alır? Bu bölüm, tasarımın en çok puan getiren kısmıdır.

Kavramsal Örnek: Kısa Bağlantı Servisi

Aşağıdaki örnek, yukarıdaki adımların nasıl uygulandığını göstermek için kurgulanmıştır; gerçek bir ölçüm veya üretim deneyimine dayanmaz.

Gereksinimler: Uzun URL'yi kısaya çevirme, kısa URL'yi uzuna yönlendirme, yüksek okuma oranı, kısa kodların çakışmaması.

Temel kararlar:

• Yazma seyrek, okuma yoğun olduğu için okuma yolunu önbelleğe uygun tasarla.
• Kısa kod üretiminde benzersizlik gerekir; merkezi bir sayaç veya rastgele üretim + çakışma kontrolü gibi yaklaşımlar ödünleşimleriyle tartışılır.
• Yönlendirme isteği durumsuz servislerle karşılanır; böylece yatay ölçeklenir.
• Depolama için anahtar-değer modeli doğal bir adaydır; ancak analitik sorgular gerekiyorsa ayrı bir depo düşünülür.

Kod örneği (kavramsal): Aşağıdaki parça, kısa kod üretiminde benzersizliği nasıl ele alabileceğini göstermek için yazılmıştır. Belirli bir dil sürümüne bağlı değildir ve çalıştırıldığı iddia edilmez.

fonksiyon kisa_kod_uret(uzun_url):
    kod = rastgele_taban62(uzunluk = 7)
    eger depoda_var_mi(kod):
        # Çakışma durumunda yeniden dene
        dön kisa_kod_uret(uzun_url)
    depoya_yaz(kod, uzun_url)
    dön kod

Bu yaklaşımın beklenen davranışı, kod uzayı büyük olduğu sürece çakışma olasılığının düşük kalmasıdır; ancak çakışma kontrolü yine de zorunludur. Alternatif olarak merkezi bir sayaç kullanmak çakışmayı tamamen ortadan kaldırır, karşılığında tek nokta bağımlılığı ve kodların tahmin edilebilirliği gibi bedeller getirir.

Yaygın Hatalar

• Gereksinimleri atlayıp doğrudan çizmeye başlamak: Soruyu netleştirmeden şema çizmek, yanlış problemi çözme riskini artırır.
• Teknoloji adı saymak: "Şu veritabanını kullanırız" demek yetmez; neden o veritabanı, hangi erişim deseni için?
• Ölçek hesabı yapmamak: Hangi bileşenin darboğaz olacağını gösteremezsen tasarım savunmasız kalır.
• Tek nokta arıza bırakmak: Yük dengeleyici, veritabanı veya önbellek için çökme senaryosunu konuşmamak.
• Tutarlılığı görmezden gelmek: Kullanıcıya ne zaman "tamam" dediğin, mimariyi doğrudan etkiler.
• Sadece mutlu yolu anlatmak: Hata, yeniden deneme ve kısmi başarısızlık durumları mülakatın ayrılmaz parçasıdır.
• Aşırı mühendislik: Gereksinimde olmayan ölçek için karmaşık çözümler önermek, basit ve yeterli bir tasarımdan daha zayıf görünür.

Güvenlik Etkileri

Sistem tasarımı tartışmasında güvenlik, sonradan eklenen bir katman değil tasarım kararıdır. Konuya uygun başlıca noktalar:

• Kimlik doğrulama ve yetkilendirme: Servisler arası çağrılarda kimlik nasıl taşınacak, yetki nerede kontrol edilecek?
• Girdi doğrulama: Dışarıdan gelen her veri güvenilmez kabul edilir; yönlendirme servislerinde açık yönlendirme (open redirect) riski gibi konular tasarımda düşünülmelidir.
• Veri koruma: Aktarımda ve durağan halde şifreleme; hassas alanların loglanmaması.
• Hız sınırlama: Kötüye kullanım ve kaynak tükenmesine karşı sınırların nerede uygulanacağı.
• En az yetki: Her servisin yalnızca ihtiyaç duyduğu kaynağa erişmesi.
• Sır yönetimi: Anahtarların kod içinde değil, merkezi bir sır deposunda tutulması.

Bu maddeleri tasarımına yerleştirirken "hangi tehdit modeli?" sorusunu sor; her senaryoya aynı çözümü uygulamak yerine riski konuş.

Çalışma Planı

Zamana dayanıklı bir hazırlık için şu döngü işe yarar:

1. Kavramları oku: Tutarlılık modelleri, CAP ödünleşimi, önbellekleme stratejileri, kuyruk semantiği, parçalama.
2. Küçük sistemleri uçtan uca tasarla: Kısa bağlantı, akış (feed), bildirim, dosya yükleme gibi tanıdık problemleri kağıtta çöz.
3. Kendini süreyle: 35-45 dakikalık oturumlar hâlinde pratik yap; gereksinim, tasarım, derinleşme ve darboğaz bölümlerini ayır.
4. Sesli düşün: Varsayımlarını yazılı veya sözlü olarak ifade etme alışkanlığı kazan.
5. Geri bildirim al: Tasarladığın sistemi bir meslektaşına anlatıp sorularına cevap ver.

Kapanış

Sistem tasarımı mülakatı, doğru cevabı bilme yarışı değil; belirsizlik altında gerekçeli karar verme pratiğidir. Gereksinimleri netleştir, büyüklükleri sayısallaştır, her bileşenin neden orada olduğunu açıkla ve tasarımının nasıl kırılabileceğini kendin söyle. Bu yaklaşım hem mülakatta hem de üretimde aynı şekilde işe yarar.