1. GİRİŞ

Sistem tasarımı mülakatları (system design interviews) yazılım mühendisliği işe alım süreçlerinin en zorlu bölümlerinden biridir. Özellikle orta ve kıdemli seviye rollerde, adayın geniş ölçekli sistemleri analiz etme, uygun teknolojileri seçme, trade‑off'ları değerlendirme ve operasyonel gereksinimleri dikkate alarak pratik çözümler üretme becerisi ölçülür. Bu nedenle sadece tek bir doğru cevap yoktur; adayın yaklaşımı, problem çözme adımları, varsayımları ve iletişimi değerlidir.

Bu konu neden bugün önemli?

Bulut, mikroservisler, gerçek zamanlı sistemler ve AI tabanlı uygulamaların yükselişi, sistem tasarımı becerilerinin önemini artırdı. İş dünyasında ölçeklenebilir, güvenilir ve maliyet‑etkin çözümler kurmak kritik olduğundan, mülakatlarda gerçek dünya deneyimini yansıtan sorular artıyor. Ayrıca ekipler artık sadece kod yazan değil; tasarım, izlenebilirlik ve operasyonu düşünen mühendisler arıyor.

Kimler için önemli?

• Kıdemli ve kıdem öncesi yazılım mühendisleri
• Teknik liderler ve çözüm mimarları
• Sistem tasarımı üzerine eğitim veren eğitmenler
• Mülakat yapanlar: hiring managers ve interviewers — ortak değerlendirme dili için

Hangi problemleri çözüyor?

• Ölçeklenebilir veri akışı, yüksek eşzamanlılık, düşük gecikme ve dayanıklılık gereksinimlerinin tasarımı
• Performans, maliyet ve operasyon arasında bilinçli trade‑off kararlarının alınması
• Güvenlik, gözlemlenebilirlik ve recovery planlarının entegre edilmesi

2. KAVRAMSAL TEMELLER

Sistem tasarımında ortak dil oluşturmak için temel kavramları ve terminolojiyi tanıyalım. Bu başlıklar mülakat sırasında hızla referans alınır.

2.1. Temel Tanımlar

• Throughput: Bir sistemin birim zamanda işlediği istek sayısı (ops/sec).
• Latency: Bir isteğin cevaplanma süresi; p99, p95 gibi percentil ölçümleri kullanılır.
• Availability: Sistem kullanılabilirlik oranı; SLA ve SLO terimleriyle ilişkilidir.
• Consistency: Verinin farklı okumalarda tutarlı olması; eventual, strong consistency gibi modeller vardır.
• Partitioning / Sharding: Veri veya iş yükünü parçalara bölme; yatay ölçeklenebilirlik sağlar.
• Replication: Veri çoğaltma; okuma ölçeklendirme ve dayanıklılık sağlar.
• Cache: Sık erişilen veriyi bellek katmanında tutma; latency'yi düşürür ama invalidation gerektirir.
• CQRS: Command Query Responsibility Segregation — yazma ve okuma yollarını ayırma desenidir.
• Event Sourcing: Sistemdeki durum değişikliklerinin event olarak saklanması; audit ve replay imkânı sağlar.

2.2. Yaygın Bileşenler

• Load Balancer: İstemciden gelen istekleri backend örneklerine yönlendirir (Layer 4 veya Layer 7).
• API Gateway: Authentication, rate limiting, routing, protocol translation ve monitoring sağlar.
• Service Discovery: Mikroservislerin birbirlerini bulmasını sağlar (Consul, DNS, etcd).
• Message Queue / Broker: Asenkron iletişim ve decoupling için (Kafka, RabbitMQ, SQS).
• Databases: RDBMS, NoSQL, NewSQL ve distributed SQL seçenekleri.
• Monitoring / Tracing: Metrics (Prometheus), Tracing (OpenTelemetry/Jaeger), Logs (ELK)

3. NASIL ÇALIŞIR? — MÜLAKATTA YAKLAŞIM VE TEKNİK MİMARİ

Bir sistem tasarım sorusuna yaklaşmak disiplin, yapı ve iletişim gerektirir. İşte adım adım ideal bir süreç ve teknik bakış açıları.

3.1. Mülakat Yaklaşımı — 5 Adımda Problem Çözümü

1. Problem Tanımı ve Kısıtlar: Soruyu netleştirin. İsteklerini tekrar edin, eksik parametreleri sorun (trafik, veri miktarı, SLA, latency beklentisi, read/write oranı).
2. Varsayımlar: Cevap verirken hangi varsayımlarda bulunduğunuzu açıkça söyleyin (ör. 100k req/s, 1TB veri büyüklüğü). Bu, interviewer ile ortak zemin oluşturur.
3. Yüksek Seviye Tasarım: Sistemi blok seviyesinde çizin: load balancer, API gateway, uygulama katmanı, veri katmanı, cache, queue, background workers.
4. Derinlemesine Tasarım: Kritik bileşenleri seçin ve detaylandırın: veri modeli, partitioning stratejisi, replication, cache invalidation, failure senaryoları.
5. Ops ve Non‑functional Gereksinimler: Monitoring, fallback, rate limiting, security, scaling planları ve maliyet analizini tartışın.

3.2. Örnek Mülakat Sorusu: "URL Shortener"

Kısa bir uygulama üzerinden pratik adımları görelim. Amaç: istek başına tasarım düşüncesini göstermek; detaylar az çok değişebilir.

• Hedefler: kısa URL oluşturma, redirect performansı (low latency), çakışma olmaması, istatistik toplama.
• Yükseklik varsayımı: 100M kısa URL, 1M req/s okumalar, 10k req/s yazmalar.
• Yüksek seviye: API Gateway → Application Servers (hashing/encode) → Database (sharded key‑value store) + Cache (CDN/Redis) → Analytics pipeline (Kafka → Hadoop/Spark).
• Key decisions: short id generation (base62, hash + collision handling, or sequential with randomness), TTL ve soft delete, CDN ile global redirect performansı, rate limiting, and abuse prevention.

3.3. Veri Modeli ve Partitioning

Veri modeli basit görünse de erişim paternleri tasarımda belirleyicidir. Okuma ağırlıklı sistemlerde read‑optimized storage ve caching öne çıkar. Partitioning stratejisi (hash by short id) hot partitions'ı önlemek için önemlidir.

3.4. Caching ve CDN

Redirect latency'si kritik olduğundan CDN ile edge cache kullanmak genelde en iyi yaklaşımdır. Cache invalidation politikası (TTL, manual purge) ve cache miss handling net olmalıdır.

3.5. Observability ve Failure Handling

Redirect'lerde p99 latency'yi izlemek, 5xx rate, cache hit ratio ve region bazlı hata oranları izlenmelidir. Fallback senaryoları: DB read fail → serve generic page veya retry with exponential backoff.

4. GERÇEK DÜNYA KULLANIMLARI

Büyük şirketlerin gerçek dünya sistem tasarım tercihleri pratikte hangi trade‑off'ları seçtiklerini gösterir. Aşağıda örnekler ve nedenleri özetlenmiştir.

Netflix

Yüksek throughput, düşük gecikme ve global dağıtım ihtiyaçları nedeniyle Netflix, büyük ölçüde event‑driven, asenkron ve cache‑agresif yaklaşımlar kullanır. Özellikle CDN ve edge caching video teslimatında kritiktir; kontrol düzlemleri mikroservislerle yönetilir.

Uber

Lokasyon duyarlı dispatch ve fiyatlandırma sistemleri düşük latency ve consistency gerektirir. Uber, locality, data partitioning ve güçlü monitoring kombinasyonlarıyla yüksek güvenilirlik sunar.

Amazon (AWS)

AWS, servis düzeyinde yüksek konfigurasyon esnekliği sunar: managed queues, elastic DB, caching ve global load balancing. Tasarım kararları müşterinin maliyet ve performans gereksinimlerine göre şekillenir.

OpenAI

Model serving ve inference platformları yüksek GPU kullanımı, batching, rate limiting ve autoscaling gerektirir. Sorgu yönlendirmesi, model versiyonlama ve resource scheduling kritik unsurlardır.

Stripe

Ödeme sistemleri yüksek tutarlılık ve audit gerektirir. Stripe, idempotency, reconciliation, strong consistency ve çok sıkı operasyonal kontrol kullanır. Transactional integrity önceliklidir.

5. AVANTAJLAR VE SINIRLAMALAR

Avantajlar

• Sistem tasarım mülakatları adayın geniş perspektifini, trade‑off düşüncesini ve iletişimini ölçer.
• Gerçek dünyaya yakın problemlerle uygulama yetkinliğini test eder.
• Departmanlar arası teknik terim birliği sağlar; hiring için objektif kriterler koyar.

Sınırlamalar

• Mülakat şartları yapaydır: Gerçek üretim verileri, politika ve organizasyonel kısıtlar her zaman yansıtılamaz.
• Time‑boxed format bazı derin teknik seçimleri yüzeysel kılar; doğru iletişim ve varsayımlar önem kazanır.
• Yanlı değerlendirme riski: interviewers'ın farklı beklentileri adayı etkileyebilir; rubric ve standart sorular önemli.

6. ALTERNATİFLER VE KARŞILAŞTIRMA

Sistem tasarımında sık kullanılan yaklaşımları teknik avantaj ve dezavantajlarıyla karşılaştıralım.

7. EN İYİ PRATİKLER

Mülakatlarda ve gerçek projelerde uygulanabilecek uzman tavsiyeleri aşağıdadır. Kod örneği yoktur; mimari, operasyon ve güvenlik odaklıdır.

Preparation for Interviews

• Temel kalıpları ve distributed systems konseptlerini (CAP, consensus, leader election) iyi öğrenin.
• Örnek problemler üzerinde çalışın: URL shortener, rate limiter, chat system, news feed, metric aggregator gibi.
• Varsayımları açıkça ifade etmeyi ve gerektiğinde interviewer ile hizalanmayı pratik edin.

Production Practices

• Design for failure: her bileşenin başarısızlığına karşı fallback planı hazırlayın.
• Observability first: tracing, metrics ve structured logging sistemi tasarımın ayrılmaz parçası olmalı.
• Security ve privacy by design: authentication, authorization, encryption ve PII handling düşünün.

Performance & Scalability

• Cache, queue ve async processing ile latency/throughput trade‑off'larını optimize edin.
• Partitioning ve replication stratejilerini test edin; hot key mitigations planlayın.
• Autoscaling ve capacity planning ile maliyeti optimize edin.

8. SIK YAPILAN HATALAR

• Problem tanımını atlayıp hemen detaylara girmek: requirements yanlış anlaşılabilir.
• Varsayımları gizlemek: interviewer sizin düşünce sürecinizi takip edemez.
• Non‑functional gereksinimleri (SLA, budget, ops) göz ardı etmek.
• Observability ve ops planını unutarak sadece fonksiyonel tasarıma odaklanmak.
• Çözüme tek doğruymuş gibi davranmak; alternatifleri tartışmamak.

9. GELECEK TRENDLER

AI‑Assisted Design ve Automated Architecture Review

AI araçları mimari taslaklarını analiz edip potansiyel darboğazları, güvenlik açıklarını veya maliyet yükseltecek konfigürasyonları işaretleyebilecek. Bu, mülakat hazırlığında da referans kontrolü olarak kullanılacak.

Platform Engineering ve Standardized Building Blocks

Organizasyonlar repeatable, güvenli ve maliyet‑etkin altyapı kurmak için platform mühendisliği yaklaşımlarını benimseyecek; interview soruları bile kurum spesifik building block'lar üzerinden şekillenebilir.

Observability ve SRE Entegrasyonu

Mülakatlarda gözlemlenebilirlik ve operasyonel hazırlık artık lüks değil zorunluluk olacak; SRE ilkeleri sistem tasarımının merkezine oturacak.