Idempotency Key ve Exactly-Once Miti: Dagitik Sistemlerde Gercekci Yaklasim

Dagitik sistemlerde "exactly once" ifadesi sik kullanilir ama gercekte cogu ekip "at least once + deduplication" modeliyle calisir. Timeout, retry ve baglanti kopmalari nedeniyle tekrar istekler normaldir.

Bu nedenle write islemlerinde en guvenli yaklasim idempotency key kullanmaktir.

Tekrar istekler neden olusur?

• Istek serverda basarili olur ama istemci timeout alir
• Reverse proxy gecici hata gorup yeniden dener
• Kullanici ayni aksiyonu iki kez tiklar
• Queue consumer crash oldugu icin mesaj tekrar gelir

Temel akis

Her isleme ait sabit bir key uretin. Key daha once gorulduyse ayni sonucu donun, gorulmediyse islemi calistirip sonucu key ile birlikte kalici yazin.

Request(idempotency_key=abc123)
  -> key lookup
  -> varsa: onceki sonucu don
  -> yoksa: islemi calistir + sonucu atomik kaydet

Uretim ortami kurallari

1. Key'i tenant/user kapsaminda degerlendirin.
2. Basarili ve bilinen is kurali hatalarini da kaydedin.
3. Key TTL suresini retry penceresiyle uyumlu secin.
4. Veri katmaninda unique constraint ile koruyun.

Sık yapilan hatalar

• Her retry denemesinde yeni key uretmek
• Yan etki olustuktan sonra key kaydetmek
• Duplicate isteklerde sadece 409 donup onceki cevabi replay etmemek
• Downstream non-idempotent cagrilari guvenli varsaymak

Sonuc

Exactly-once cogu zaman uctan uca garanti degildir. Idempotency key, tekrar istekleri kontrol altina alip write API davranisini ongorulebilir hale getirir.