Mesaj Kaç Kez Gelir?

Neden garanti seçmek zorundasın?

Şu basit soruyla başlayalım: mesajı gönderdin, cevap gelmedi. Ne oldu?

• Mesaj hiç gitmedi.
• Mesaj gitti, işlendi, ama onay dönerken kayboldu.

Gönderen tarafta bu ikisi birbirinden ayırt edilemez. İkisi de aynı görünüyor: sessizlik. Ve verebileceğin sadece iki karar var:

• Tekrar gönder → mesaj kaybolmaz ama iki kez işlenebilir. Bu at-least-once.
• Gönderme → iki kez işlenmez ama kaybolabilir. Bu at-most-once.

Üçüncü bir seçenek yok. Bütün konu bu tek belirsizlikten çıkıyor.

At-most-once: kaybolan tick meselesi

Fiyat akışı genelde UDP üzerinden gelir ve UDP hiçbir söz vermez: paket düşerse düşer, kimse tekrar göndermez. İlk duyduğunda insana yanlış geliyor — niye TCP kullanmıyoruz?

Çünkü tick’in tekrarı işe yaramaz. 50 ms önceki EURUSD fiyatını yeniden almanın hiçbir değeri yok; zaten yenisi geldi. TCP’nin tekrar denemesi için harcadığı süre, veriyi kurtarmak yerine bütün akışı geciktirir. Kayıp burada kabul edilebilir; gecikme değil.

class Kotasyon {
    String  sembol;
    double  bid, ask;
    long    kaynakZamani;   // saglayicinin damgasi
    long    varisZamani;    // bizim aldigimiz an
    long    sira;           // saglayicidan gelen artan numara
}

// Emir acmadan ONCE:
long yas = simdi() - kotasyon.varisZamani;
if (yas > STALE_ESIGI_MS) {          // orn. 500 ms
    reddet("stale quote: " + yas + " ms");
}

At-least-once: iki kez gelen fill

Şimdi asıl mesele. Emir, fill, bakiye hareketi — bunların kaybolması kabul edilemez, dolayısıyla at-least-once kullanıyorsun. Yani tekrar gelecek.

Nasıl oluyor, tek tek:

Dördü de normal işleyiş. Hiçbiri hata değil. Yani “tekrar gelmesin” diye uğraşmak yanlış yol; doğru yol “iki kez gelirse ne olacak” sorusuna cevap vermek.

Exactly-once neden bir efsane (ve gerçekte ne var)

“Exactly-once destekliyoruz” cümlesini duyduğunda sorulacak soru şu: teslimde mi, işlemede mi?

• Exactly-once delivery (tam bir kez teslim): mümkün değil. Yukarıdaki belirsizlik — onay mı kayboldu, mesaj mı — ortadan kalkmıyor.
• Exactly-once processing (tam bir kez işleme): mümkün. Yöntemi de belli: at-least-once teslim + tekrarları eleyen tüketici.

Kafka’nın exactly-once’ı da bu ikinciye giriyor ve bir şartı var: hem okuma hem yazma Kafka’nın içinde olmalı. Kafka’dan okuyup PostgreSQL’e yazıyorsan o garanti seni kapsamıyor — orada dual write sorununa girmiş oluyorsun.

İlaç 1: Idempotency key (request path)

Emri gönderen taraf, her mantıksal emir için tekil bir anahtar üretir ve tekrar denemelerde aynı anahtarı gönderir.

-- Anahtar tablosu, tekil kisit sart
CREATE TABLE istek_anahtarlari (
  anahtar    text PRIMARY KEY,       -- client_order_id
  hesap_id   bigint NOT NULL,
  sonuc      jsonb,                  -- ilk cevabin kopyasi
  olusma     timestamptz NOT NULL DEFAULT now()
);

BEGIN;
  INSERT INTO istek_anahtarlari (anahtar, hesap_id)
  VALUES (:client_order_id, :hesap)
  ON CONFLICT (anahtar) DO NOTHING
  RETURNING anahtar;
  -- Satir donmediyse: bu istek daha once islendi.
  --   -> ISLEM YAPMA, kayitli sonucu don.

  -- Satir dondiyse: ilk kez goruyoruz, emri ac
  INSERT INTO emirler (...) VALUES (...);
  UPDATE istek_anahtarlari SET sonuc = :cevap WHERE anahtar = :client_order_id;
COMMIT;

İki ince nokta var ve ikisi de gerçek olaylardan öğrenildi:

• Anahtarı istemci üretmeli, sen değil. Sunucuda üretirsen her tekrar denemede yeni anahtar çıkar ve koruma hiç çalışmaz.
• İlk cevabı sakla ve aynısını dön. “Zaten var” diye hata dönersen istemci bunu başarısızlık sanıp yine dener. İkinci istek, birincinin cevabını almalı.

İlaç 2: Idempotent consumer (event path)

Kuyruktan gelen fill bildirimi için istemci yok; anahtarı olayın kendisi taşıyor (fill_id, deal_id, event_id). Tüketici, bu kimliği görüp görmediğine bakar.

BEGIN;
  INSERT INTO islenen_olaylar (olay_id, tur)
  VALUES (:fill_id, 'FILL')
  ON CONFLICT (olay_id) DO NOTHING
  RETURNING olay_id;
  -- Satir donmediyse: bu fill zaten islenmis -> COMMIT ve cik

  -- Ilk kez: asil isi yap
  INSERT INTO fill_kayitlari (...) VALUES (...);
  UPDATE pozisyonlar
     SET lot = lot + :lot, ort_fiyat = ...
   WHERE id = :pozisyon_id;
COMMIT;

Dedup tablosu sonsuza kadar büyümez

Günde milyonlarca olay geliyorsa bu tablo bir yıl sonra ana yükün kaynağı olur. Pratik yaklaşım:

• Bir pencere belirle. Tekrarlar dakikalar içinde gelir, aylar sonra değil. 7 gün fazlasıyla yeterli.
• Eskiyi temizle. Günlük bir iş: DELETE FROM islenen_olaylar WHERE olusma < now() - interval '7 days'. Tarih alanına indeks koy, yoksa temizlik işi tabloyu kilitler.
• Pencere dışını da düşün. Pencere dolduktan sonra gelen bir tekrar yeniden işlenir. Kabul edilemezse asıl tabloda da tekil kısıt (unique constraint) olsun — ikinci savunma hattı.

Peki hangi veri için hangisi?

Karar vermenin en kolay yolu tek soru: bu mesajı kaybetmek mi daha kötü, iki kez işlemek mi?

Dikkat: aynı sistemde ikisi birden olur ve olmalıdır. Fiyat akışını at-least-once yapmak gecikmeyi öldürür; emirleri at-most-once yapmak parayı öldürür. Tek bir garantiye standart diye sarılmak, iki taraftan birinde mutlaka yanlış olmak demek.

Sahadan: çift fill’i nasıl kapattık

Baştaki olaya dönelim. Aynı fill iki kez geldi ve iki kayıt açıldı. İlk refleks “köprüyü düzeltelim, iki kez göndermesin” oldu. Yanlış refleks: köprü doğru davranıyordu, onay alamadığı için tekrar gönderiyordu.

Yaptığımız üç şey:

1. deal_id üzerinde tekil kısıt. Uygulamada bir kontrol değil, veritabanında bir yasak. Kaç kopya çalışırsa çalışsın kural tek yerde.
2. Dedup ile pozisyon güncellemesi aynı transaction’a alındı. Öncesinde ayrıydılar ve arada bir çökme “işlendi ama yazılmadı” üretmişti — ki bu çift kayıttan daha zor fark edilir.
3. Tekrar sayacı metriğe döküldü. tekrar_gelen_olay_toplam sıfır olmuyor, olmasını da beklemiyoruz. Ama sayı zıplarsa bu genelde köprüde ya da ağda bir sorunun ilk işareti oluyor. Yani dedup sadece koruma değil, aynı zamanda bir sensör.

Kontrol listesi AI agent görev listesi

Sonuç

Teslim garantisi seçmek teknik bir tercih gibi görünüyor ama aslında ticari bir tercih: neyi kaybetmeyi göze alıyorsun? Fiyatta kaybı göze alıyorsun çünkü yenisi geliyor. Fill’de göze almıyorsun çünkü para.

Ve aklında tek cümle kalsın: exactly-once bir teslim garantisi değil, bir tüketici tasarımıdır. Kimse sana onu satamaz; onu sen yazarsın, üstelik sekiz satırlık bir ON CONFLICT DO NOTHING ile.