Ağır çekişme altında bir hot key veya hot row'u nasıl ele alırsınız?

Question

IT Interview Practice · Accepted Answer

**Tüm trafiği tek bir key'e yönlendirmeyi bırakın: hot key'i N alt key'e bölün (sharded counter'lar), duplicate okumaları coalesce edin, bir local cache'ten sunun ve yazmaları batch'leyin, böylece bir satır her istekte güncellenmesin.** Viral bir gönderideki tek bir "likes" sayacı saniyede 50k yazma alabilir — her transaction aynı kilit için savaşırken bir satır bir serialization bottleneck'i haline gelir.

## Tek çekişen satır yerine fan-out

```text
                 50k inc/sec on post:123
                          │
             hash(request) % N   (split the key)
        ┌────────┬────────┬────────┬────────┐
        ▼        ▼        ▼        ▼        ▼
   likes:123:0  :123:1  :123:2  :123:3  :123:4   ← sharded counters
        └────────┴───┬────┴────────┴────────┘
                     ▼
             SUM on read = total     (read fans in)
```

## Teknikler

- **Sharded counter / key splitting.** Rastgele seçilen `likes:123:{0..N}`'e yazın; gerçek sayı `SUM`'dır. Bu, tek bir hot row'u N daha serin satıra dönüştürür, lock contention'ı ~N kesir. Okumalar küçük bir fan-in maliyeti öder.
- **Request coalescing (single-flight).** 10k istek aynı anda aynı key'i istiyorsa, **bir**'inin DB'ye çarpmasına izin verin ve geri kalanının o in-flight sonucu beklemesini sağlayın. Bir cache-miss stampede'inin satırı ezmesini önler.
- **Local (in-process) cache.** Hot değeri her app node'unda kısa bir TTL için cache'leyin (örn. 1s). Bir read-hot key için, bu saniyede binlerce okumayı bir refresh'e daraltır — hafif staleness kabul ederek.
- **Write batching.** Artışları bellekte buffer'layın ve 500 tek güncelleme yerine saniyede bir `+= 500` flush edin. Saniyede 500 yerine saniyede bir satır güncellemesi çekişmeyi tamamen kaldırır.

## Mülakat perspektifi

Mülakatı yapan kişi, **çekişmenin nerede olduğunu** teşhis ettiğinizi ve düzeltmeyi read-hot vs write-hot ile eşleştirdiğinizi görmek ister. Read-hot → cache + coalescing; write-hot → sharded counter + batching. İyi cevap teknikleri listeler; harika cevap, sharding'in **read maliyetini write scalability için** takas ettiğini ve batching/caching'in **freshness'ı throughput için** takas ettiğini belirtir.

**Ödünleşimler & tuzaklar:** sharded counter'lar tam gerçek zamanlı toplamları zorlaştırır (shard'ları toplarsınız) ve "sıfırın altına decrement" mantığını karmaşıklaştırır. Local cache'ler node'lar arasında kayar — bir like sayısı için iyi, bir banka bakiyesi için yanlış. Batching, bir node flush'tan önce çökerse buffer'lanmış yazmaları kaybetme riski taşır, bu yüzden idempotent/yaklaşık sayaçlara uygundur, paraya değil. Verinin consistency ihtiyaçlarının izin verdiği hafifletmeyi seçin.

Tek çekişen satır yerine fan-out

Teknikler

Mülakat perspektifi

İlgili sorular