Load Shedding Nedir? Trafik Patlayınca Sistemi Nazikçe Yavaşlatma Sanatı

Trafik her zaman “yavaş yavaş” artmaz. Kampanya, push bildirimi, beklenmedik bir bot akını… Bir anda 10x yük geldiğinde iki seçenek vardır: ya her şeyi denersiniz ve çökersiniz, ya da bazı şeylerden geçici olarak vazgeçip çekirdeği ayakta tutarsınız. İşte bu ikinci yaklaşım: load shedding.

Load Shedding neyi çözer?

Amaç “her isteğe cevap vermek” değil; kritik işlevleri (login, ödeme, sipariş oluşturma) koruyup, daha az kritik işleri (öneriler, raporlar, arama filtreleri, analitik event’leri) kontrollü şekilde kısmaktır.

Bunu yapmazsanız genelde şu olur:

• Thread/connection havuzları dolar
• DB CPU ve lock’lar artar
• Kuyruklar şişer
• Zaman aşımları “retry storm” yaratır
• Sonunda kritik endpoint’ler de düşer

Load shedding stratejileri (pratik)

1) Erken reddetme (fail fast)

Uygulama “içeri alıp bekletmek” yerine, kapasite dolunca hızlıca 429/503 döner. Bu sayede kaynaklar (CPU, DB connection) boşa harcanmaz.

Örnek:

• /checkout her zaman çalışsın
• /search yoğunlukta 503 + Retry-After: 2 dönebilsin

2) Önceliklendirme (priority lanes)

Tüm istekler eşit değildir. Basit bir sınıflandırma bile çok fark eder:

• Tier-0: ödeme, sipariş, kimlik doğrulama
• Tier-1: ürün detayı, sepet görüntüleme
• Tier-2: arama, öneri, raporlar

Uygulama: ayrı thread pool / ayrı queue / ayrı rate limit. Tier-2 baskın gelince Tier-0 etkilenmez.

3) Kısmi yanıt (degrade gracefully)

Bazı parçaları kapatıp sayfayı/cevabı “daha ucuz” hale getirirsiniz.

E-ticaret örneği:

• Öneri widget’ı yerine “Popüler ürünler” cache’ten
• Yorumlar sayısı yerine “Yorumlar geçici olarak kapalı”
• Filtre kombinasyonlarını azaltma (örn. sadece marka + fiyat)

4) Örnekleme (sampling)

Her olayı işlemek zorunda değilsiniz.

Örnek:

• Analitik event’lerini %10 örnekle
• Debug log’u kapat, sadece error log bırak
• Arama metriklerini 1/5 oranla gönder

5) Kuyruk koruması (queue shedding)

Kuyruğa sınırsız iş basmak, problemi gecikmeyle büyütür. Kuyruğa girişte kapasite kontrolü yapın.

Kural: “Kuyruk dolduysa yenisini alma.”

• Ya isteği reddet
• Ya “later processing” seçeneği sun

6) Timeout bütçesi (latency budget)

Bir isteğin toplam süresi 800ms ise:

• DB: 200ms
• downstream servis: 300ms
• uygulama: 300ms

Bütçe aşılınca beklemek yerine fallback’e dönün. Aksi halde domino etkisi olur.

Mini örnek: Node.js’te basit concurrency gate

Aşağıdaki yaklaşım, sunucuda aynı anda işlenen istek sayısını sınırlandırıp dolunca 503 döner.

import express from "express";

const app = express();
const MAX_INFLIGHT = 200;
let inflight = 0;

app.use((req, res, next) => {
  // Kritik endpoint'lere öncelik verebilirsiniz
  const isCritical = req.path.startsWith("/checkout") || req.path.startsWith("/login");

  if (!isCritical && inflight >= MAX_INFLIGHT) {
    res.set("Retry-After", "2");
    return res.status(503).json({ error: "Server busy, try again." });
  }

  inflight++;
  res.on("finish", () => inflight--);
  next();
});

app.get("/search", async (req, res) => {
  // pahalı iş
  await new Promise(r => setTimeout(r, 120));
  res.json({ items: [] });
});

app.post("/checkout", async (req, res) => {
  await new Promise(r => setTimeout(r, 80));
  res.json({ ok: true });
});

app.listen(3000);

Bu tek başına “mucize” değildir ama şunu sağlar: sistem kontrollü bozulur.

Ne zaman load shedding’e ihtiyaç var?

• Trafik burst’leri yaşıyorsanız (kampanya, canlı yayın, bilet satışı)
• DB bağlantı havuzu sık doluyorsa
• Zaman aşımı sonrası retry’lar artıyorsa
• “Her şey yavaşladı” şikayetiyle birlikte error oranı da yükseliyorsa

Üretimde uygulanabilir 5 kontrol listesi maddesi

1. Kritik endpoint listesi çıkarın (hangileri asla kesilmez?).
2. Her kritik olmayan endpoint’e fallback tanımlayın.
3. 503/429 dönüşlerinde Retry-After kullanın.
4. Kuyruklar için maksimum uzunluk ve drop policy belirleyin.
5. Trafik artınca otomatik devreye giren degrade modu ekleyin (feature config ile).

Load shedding’in özeti: Her şeyi kurtarmaya çalışıp batmak yerine, en değerli parçayı koruyup geri kalanını geçici olarak kısmak. Doğru tasarlanırsa kullanıcı “hizmet yok” yerine “biraz sadeleşmiş ama çalışan” bir deneyim görür.