Blog
Mert Özen'in yazılım geliştirme, backend, frontend ve DevOps üzerine blog yazıları.
System Design Case Study: Flash Sale ve Bilet Satışı
Flash sale'de overselling'i önleyen şey stok kontrolü ile azaltmanın tek atomik adımda yapılmasıdır; ani trafiği CDN'den sunulan bir waiting room emer, ödeme süresini TTL'li hold'lar yönetir, süresi dolan hold stoğu aynı statement'ta geri verir. 2.000 eşzamanlı alıcıyla 100 bilete naif kodun 2.000 rezervasyonu, koşullu UPDATE ve optimistic concurrency'nin gerçek çıktıları, ödeme timeout'u ve bot savunması.
System Design Case Study: Chat ve Notification Sistemi
Chat sisteminde bağlantılar stateful gateway'lerde, sıra ve kayıt stateless bir chat service'te durur: mesaj önce kaydedilir, sohbet başına sunucu sayacıyla sıra numarası alır, alıcının gateway'i presence kaydıyla bulunur, çevrimdışı alıcıya push gider. İki gateway arasında Redis ile yönlendirme ve istemci tarafında seq ile sıralama, dedupe ve boşluk tespitinin gerçek çıktıları, okundu bilgisi, grup fan-out'u ve mesaj saklama.
System Design Case Study: News Feed ve Timeline
News feed'de varsayılan fan-out on write'tır, ama takipçi dağılımı power-law olduğu için tek bir ünlü paylaşımı milyon yazmaya dönüşür; çözüm, yüksek bir eşiğin üstündeki hesapları okuma anında birleştiren hibrit model, yalnız post ID tutan bir feed cache ve cursor pagination. Hesaplanmış capacity tablosu, push, pull ve hibrit simülasyonu, Redis sorted set'te offset ile cursor'ın gerçek çıktıları.
System Design Case Study: URL Shortener Tasarlamak
URL shortener okuma ağırlıklı bir sistemdir: saniyede ~40 yazmaya karşı ~3.900 redirect, bu yüzden stateless bir redirect yolu, cache-aside, çakışmasız ve tahmin edilmesi zor kodlar ve analytics için 301 değil 302 gerekir. Hesaplanmış capacity tablosu, hash çakışmalarının gerçek ölçümü, sayaç + bijective dönüşüm + base62, 301/302 curl çıktıları, alias, expiration ve kötüye kullanım.
Unique ID Üretimi: Auto-Increment, UUIDv4, UUIDv7 ve Snowflake
Sharding'li ya da çok instance'lı bir sistemde ID seçimi benzersizlik, sıralanabilirlik, boyut, koordinasyon ve ID'nin dışarıya ne sızdırdığı arasında bir trade-off'tur: UUIDv7 koordinasyonsuz ve index dostu, Snowflake 64 bite sığar ama worker ID ve saat yönetimi ister. .NET'in CreateVersion7'sinin milisaniye içinde sıra garanti etmediğinin, C# Snowflake generator'ın ve JavaScript'in 2^53 sınırının gerçek çıktıları.
Reliability Pattern'leri: Timeout, Retry, Backoff + Jitter, Circuit Breaker ve Load Shedding
Yavaş ya da çökmüş bir bağımlılığa karşı sırayla p99.9'a göre seçilmiş timeout, tek katmanda ve yalnız idempotent işlemde jitter'lı retry, retry budget, bağımlılık başına circuit breaker ve bulkhead, en sonda load shedding ve graceful degradation gerekir. Retry amplification (27 ve 243 çağrı), jitter, %10 retry budget ve circuit breaker'ın gerçek simülasyon çıktıları, failover ve .NET'in standard resilience handler varsayılanları.
Rate Limiting Tasarımı: Token Bucket, Sliding Window ve Distributed Rate Limiter
Tek bir rate limit için sayaç tek bir yerde durmalı: ASP.NET Core'un yerleşik limiter'ı sayacı her instance'ın belleğinde tuttuğu için üç instance'ta limit üç katına çıkar; çözüm gateway'de ya da Redis'te atomik bir sayaç. Beş algoritmanın karşılaştırması, Redis ve Lua ile gerçek çıktılı distributed sliding window limiter, 429, Retry-After, IETF RateLimit header taslağı ve partition key'in DoS riski.
Asenkron İşleme: Queue, Worker, Fan-Out ve Backpressure
Cevabın parçası olmayan ağır işler request'ten çıkarılıp queue ve worker'lara verilir; API 202 Accepted ve bir status adresi döner. Gerçek denemede senkron fatura endpoint'i 100 eşzamanlı istekte 52 timeout üretip yine 100 PDF render ederken, bounded queue'lu sürüm 9 ms'de cevap veriyor ve dolunca 503 + Retry-After ile backpressure uyguluyor; asenkronluk işi hızlandırmıyor, zamanlamasını ayırıyor. Queue derinliğiyle autoscaling, fan-out ve at-least-once için idempotency key de yazıda.
Consistent Hashing: Hash Ring, Virtual Node'lar ve C# ile Implementasyon
Consistent hashing, node sayısı değiştiğinde key'lerin yalnız yaklaşık 1/(N+1)'ini taşıyan dağıtım yöntemidir: 4'ten 5 node'a geçişte hash % N key'lerin %80'ini taşırken C# ile yazılan hash ring 200 virtual node ile ~%20'sini taşıyor ve yükü ortalamanın ±%10'unda tutuyor. Özellikler xUnit testleriyle sabitleniyor; rendezvous hashing, Redis Cluster'ın hash slot'ları ve string.GetHashCode tuzağı da yazıda.
Veri Katmanını Ölçeklemek: Replication, Sharding ve SQL mi NoSQL mi?
Veri katmanını ölçeklemek access pattern'den başlar: replication okumayı ve availability'yi ölçekler ama yazmayı ölçeklemez, sharding yazmayı ölçekler ama shard key'i içermeyen sorguları scatter-gather'a çevirir. Bir milyon siparişlik denemede müşteri sorgusu tek shard'dan 0,1 ms'de dönerken son 30 gün sorgusu dört shard'ı baştan sona tarıyor; async replica yeni siparişi göstermiyor ve read-your-writes çözümü gerekiyor, hash % N ile 4'ten 5 shard'a geçmek müşterilerin %80'ini taşıyor.
Caching Stratejileri: Cache-Aside, Write-Through, Write-Behind ve Cache Stampede
Cache-aside en yaygın strateji, ama popüler bir kaydın süresi dolduğu an bütün yük veritabanına iner: gerçek Redis denemesinde 200 eşzamanlı istek 200 sorgu üretiyor, request coalescing bunu 1'e indiriyor. Toplu ısıtılan 10.000 kayıt jitter'sız aynı saniyede sona eriyor, ±%10 jitter'la en kalabalık saniye 109 kayda düşüyor; XFetch ile erken yenileme 500 yeniden hesaplamayı 1'e indiriyor ve hot key'ler Redis'in LFU sayacıyla bulunuyor.
Load Balancing: L4 ve L7, Algoritmalar, Health Check ve Sticky Session
Load balancer'ın algoritması, bir instance yavaşladığında kullanıcının gördüğü latency'yi belirler: YARP ile yapılan gerçek denemede round robin'de p99 4,6 saniyeye çıkarken LeastRequests ve power of two choices yavaş instance'a trafiği kendiliğinden azaltıp p99'u 300 ms'de tutuyor. Çöken instance'ı ise ancak health check çıkarır (133 hatadan 35'e); L4/L7 farkı, sticky session'ın bedeli, connection draining ve GeoDNS/anycast ile global load balancing de yazıda.