System Design Araç Kutusu: Kapasite, Cache, Kuyruk, Tutarlılık ve Dayanıklılık

Son 12 ayda araç kutusunun kendisi değişmedi; değişen, araçların kullanıldığı ortam. Kleppmann ve Riccomini'nin Designing Data-Intensive Applications kitabının ikinci baskısı 2026'nın başında çıktı ve bulut servislerinin ölçekleme, hata toleransı ve tutarlılığı nasıl ele aldığını güncel örneklerle anlatıyor.

Veri katmanında PostgreSQL 18 (Eylül 2025) asenkron I/O, çok kolonlu B-tree indekslerde skip scan ve zaman sıralı uuidv7() getirdi. PostgreSQL 19, 15 Ekim 2026'da RC 1 aşamasına geldi; genel sürüm 19 Kasım 2026 için planlanıyor. Tabloyu uzun süre kilitlemeden yeniden yazan REPACK (CONCURRENTLY) ve standby'da read-your-writes için WAIT komutu bu sürümde.

Dayanıklılık tarafında iki olay dersleri tazeledi: Ekim 2025'te AWS us-east-1'de DynamoDB DNS yönetimindeki bir yarış durumu yaklaşık 14,5 saat süren zincirleme etki yarattı; Kasım 2025'te Cloudflare'de iki katına çıkan bir yapılandırma dosyası proxy'leri düşürdü. Agent tarafında MCP'nin 2026-07-28 sürümü protokolü stateless yaptı; araç sunucuları artık sıradan bir round-robin load balancer arkasında yatay ölçeklenebiliyor.

Tasarımın ilk aracı bir hesap makinesi. Back-of-the-envelope (zarf arkası) tahmin, gereksinimleri kaba sayılara çevirmek demek. Örnek: 1 milyon günlük aktif kullanıcı, kişi başı günde 20 istek atıyorsa günde 20 milyon istek eder. Bir günde 86.400 saniye var, yani ortalama yaklaşık 230 QPS (saniye başına istek). Trafik gün içinde eşit dağılmaz; tepe saatte 3-5 katı, yani 700-1.200 QPS hesaplamak daha gerçekçi.

Aynı mantık depolamaya da uygulanır. Her istek 1 KB log üretiyorsa günde 20 GB, yılda 7 TB eder. Bu sayı, logu Postgres'te tutma fikrini daha baştan eler.

Anti-pattern: hiç hesap yapmadan Kafka, Kubernetes ve üç ayrı veritabanı ile başlamak. 230 QPS'i iyi indekslenmiş tek bir Postgres ve iki uygulama sunucusu rahatça taşır. Önce sayı, sonra araç.

Ölçeklemenin üç temel kaldıracı var. Dikey ölçekleme (vertical scaling) daha büyük makineye geçmek: en ucuz ve en hızlı çözüm, ama bir tavanı var. Yatay ölçekleme (horizontal scaling) aynı servisten çok kopya çalıştırmak; bunun ön koşulu servisin stateless (durumsuz) olması, yani session bilgisini bellekte değil Redis ya da veritabanında tutması.

Veri katmanında sıralama genelde şöyle ilerler: önce sorgu ve indeks optimizasyonu, sonra okuma ağırlıklı yük için read replica (salt okunur kopya), en son partitioning ve sharding (veriyi parçalara bölmek). Read replica'nın bilinen bedeli replikasyon gecikmesidir: kullanıcı az önce yazdığını göremeyebilir. Ekim 2026'da RC aşamasındaki PostgreSQL 19, standby'ın belirli bir WAL konumuna ulaşmasını bekleyen WAIT komutuyla read-your-writes tutarlılığını kolaylaştırıyor. Sharding geri dönüşü en zor karardır; shard anahtarı yanlış seçilirse, örneğin ülke kodu, tek bir ülke tüm yükü çeker ve sıcak shard (hot shard) oluşur.

Pratik eşik: tek bir Postgres örneği iyi donanımla binlerce QPS'i kaldırabilir. Sharding'i, replica ve cache tükendiğinde ve elinizde ölçülmüş bir darboğaz olduğunda konuşun.

Cache, sık okunan veriyi pahalı kaynağın önünde tutar. En yaygın kalıp cache-aside: uygulama önce cache'e bakar, yoksa veritabanından okur ve sonucu TTL (yaşam süresi) ile cache'e yazar. Write-through kalıbında ise yazma işlemi cache ve veritabanına birlikte gider; okuma tutarlılığı artar, yazma gecikmesi uzar.

Zor kısım invalidation, yani bayat veriyi ne zaman sileceğiniz. Ürün fiyatı 5 dakika bayat kalabilir mi? Kampanya sayfasında kalabilir, ödeme ekranında kalamaz. Karar veriye göre verilir, sisteme göre değil.

Bilinen tuzak thundering herd (sürü etkisi): popüler bir anahtarın TTL'i dolduğunda binlerce istek aynı anda veritabanına iner. Çözümler: TTL'e rastgele sapma eklemek, tek bir isteğin yeniden doldurmasına izin veren kilit (request coalescing) ya da süresi dolmadan arka planda yenilemek. Hedef metrik olarak hit oranını izleyin; beklentinizin belirgin altında kalan bir hit oranı çoğu zaman yanlış anahtarlamaya ya da gereksiz kısa bir TTL'e işaret eder.

Her işin kullanıcı beklerken bitmesi gerekmez. E-posta gönderimi, fatura PDF'i üretmek ya da uzun süren bir optimizasyon hesabı çalıştırmak kuyruğa atılabilir. Message queue (mesaj kuyruğu) üretici ile tüketiciyi zamansal olarak ayırır; tüketici çökse bile iş kaybolmaz, tepe yükü düzleşir.

Kuyrukların çoğu at-least-once (en az bir kez) teslimat garantisi verir. Bu, aynı mesajın iki kez gelebileceği anlamına gelir. Bu yüzden tüketici idempotent olmalı: aynı işlemi iki kez uygulamak sonucu değiştirmemeli. Pratikte her mesaja bir idempotency key verip işlenenleri bir tabloda tutarsınız.

Klasik hata dual write: veritabanına yazıp ardından kuyruğa mesaj atmak. İkisinin arasında servis çökerse sipariş kaydedilir ama event hiç çıkmaz. Outbox pattern bunu çözer: event, aynı transaction içinde bir outbox tablosuna yazılır, ayrı bir süreç bu tabloyu okuyup kuyruğa iletir.

CAP teoremi, ağ bölünmesi (partition) anında tutarlılık ile erişilebilirlik arasında seçim yapmak zorunda olduğunuzu söyler. PACELC bunu genişletir: bölünme yokken bile gecikme ile tutarlılık arasında bir takas vardır. Pratikte soru şuna dönüşür: bu veri birkaç saniye eski görünse ne olur?

Bir gönderinin beğeni sayısı 3 saniye geriden gelse kimse fark etmez; eventual consistency (nihai tutarlılık) burada doğru seçim. Depodaki son ürünün iki kişiye birden satılması ise para ve güven kaybıdır; burada strong consistency (güçlü tutarlılık), satır kilidi ya da optimistic locking gerekir.

İyi bir alışkanlık: veri modelindeki her varlık için bir tutarlılık etiketi yazmak. Sipariş durumu güçlü, ürün yorumları nihai, öneri listesi en iyi çaba. Bu tablo, bir ajan ya da yeni bir ekip üyesi kod yazarken hangi garantiyi koruması gerektiğini açıkça gösterir.

Dağıtık sistemde bağımlılıklar yavaşlar ve düşer. Dayanıklılık (resilience) kalıpları bu hatanın tüm sisteme yayılmasını engeller. Timeout ilk savunmadır: timeout'u olmayan bir HTTP çağrısı, yavaşlayan bir servis yüzünden tüm thread havuzunuzu kilitleyebilir. Retry ikinci adımdır, ama exponential backoff (üstel bekleme) ve jitter (rastgele sapma) olmadan yapılan retry, zaten zorlanan servise saldırıya dönüşür.

Circuit breaker (devre kesici), hata oranı bir eşiği geçince, örneğin son 20 çağrının yüzde 50'si başarısızsa, çağrıları bir süre doğrudan reddeder ve bağımlılığa nefes aldırır. Rate limiting, çoğu zaman token bucket algoritmasıyla, tek bir müşterinin ya da hatalı bir ajanın sistemi boğmasını önler. Bulkhead ise kaynakları bölmelere ayırır: raporlama sorguları ödeme akışının bağlantı havuzunu tüketemez.

Yapılandırma da bir girdidir. Kasım 2025'teki Cloudflare kesintisinde boyutu beklenmedik biçimde iki katına çıkan bir özellik dosyası proxy'nin sınırını aştı ve trafik yaklaşık altı saat aksadı. Ders: config'i de doğrulayın, sınır aşılınca çökmek yerine son sağlam sürümle devam edin.

Kural: retry yalnızca idempotent işlemlere uygulanır.

Tasarım kararlarının doğru olup olmadığını ölçüm söyler. SLI (service level indicator) ölçtüğünüz şeydir, örneğin isteklerin yüzde kaçının 300 ms altında döndüğü. SLO (service level objective) bunun hedefidir. Ortalama gecikme yanıltıcıdır; p95 ve p99 (yüzdelik dilimler) gerçek kullanıcı deneyimini gösterir.

Yüzde 99,9 erişilebilirlik hedefi, 30 günlük bir ayda yaklaşık 43 dakika kesinti hakkı demek. Yüzde 99,99'a çıkmak bunu 4,3 dakikaya indirir ve maliyeti katlar. Error budget (hata bütçesi) kavramı, bu payı yeni özellik çıkarma hızıyla dengelemeyi sağlar: bütçe bittiyse önce güvenilirlik işleri yapılır.

Gözlemlenebilirliğin üç ayağı log, metrik ve trace'tir. Bir isteğin beş servis arasında nerede 2 saniye kaybettiğini distributed tracing olmadan bulmak tahmin oyunudur. Bunu tasarımın parçası olarak düşünün, sonradan eklenen bir lüks olarak değil.