Dağıtık Sistemlerde Idempotency Nedir?

19 Ekim 2026 Pazartesi

Aynı Butona İki Kere Basılırsa Ne Olur? 

Bir e-ticaret sitesinden alışveriş yaparken "Ödemeyi Tamamla" butonuna bastığınızı düşünün. Sayfa 5 saniye boyunca döner, yanıt gelmez. Kullanıcı refleksiyle o butona sabırsızca bir kez daha tıklarsınız.

Arka planda ne oldu? Banka hesabınızdan iki kez mi para çekildi, yoksa sistem durumu anlayıp tek bir sipariş mi oluşturdu?

Ağ kesintilerinin, zaman aşımlarının (timeout) ve otomatik yeniden denemelerin (retry) havada uçuştuğu dağıtık mimarilerde; bir isteğin birden fazla kez iletilmesi durumunda sistemin çığırından çıkmasını engelleyen en kritik mühendislik ilkesine Idempotency (Eşgüçlülük / Tekrarlanabilirlik) diyoruz.

Idempotency Nedir?

Matematikten yazılıma ödünç aldığımız Idempotency; bir operasyonun bir kez çalıştırılması ile aynı parametrelerle onlarca kez art arda çalıştırılması sonucunda sistemde aynı durumun (state) korunması ve ek bir yan etki (side-effect) üretmemesi prensibidir.

Matematiksel olarak f(f(x)) = f(x) eşitliğiyle ifade edilir. Örneğin bir sayıyı 1 ile çarpmak idempotent bir işlemdir (5 \times 1 \times 1 \times 1 = 5). Ancak bir sayıya 1 eklemek idempotent değildir; her çalıştırmada sonuç değişir.

Yazılım dünyasında ise idempotent bir API; istemci aynı isteği yanlışlıkla 10 kez art arda gönderse bile, işlemi yalnızca bir kez yürütür ve her defasında aynı başarılı yanıtı döner.

HTTP Dünyasında Idempotency Standartları

RESTful mimariler tasarlarken kullandığımız HTTP metotlarının doğasında yerleşik bir idempotency mantığı bulunur:

• GET, HEAD, OPTIONS (Doğal Olarak Idempotent ve Güvenli): Bir kullanıcı profilini 100 kez GET /users/42 ile sorgulamanız veritabanında hiçbir şeyi değiştirmez.
• PUT (Idempotent): PUT /users/42 ile kullanıcının adresini "İzmir" olarak güncellerseniz; bu isteği 1 kez de atsanız, 50 kez de atsanız kullanıcının adresi İzmir kalır. Yeni bir kayıt türemez.
• DELETE (Idempotent): DELETE /orders/99 isteğini ilk attığınızda sipariş silinir (200 veya 204). İkinci kez attığınızda sipariş zaten silinmiş olduğu için sistemin durumu değişmez (404 dönse bile kaynak silinmiş kalır).
• POST (Idempotent Değildir!): POST /orders isteği her çağrıldığında sistemde yeni bir kaynak üretir. Kullanıcı butona iki kez basarsa ve araya koruma konulmadıysa, veritabanına iki farklı sipariş yazılır ve karttan iki kez para çekilir.

Dağıtık Sistemlerde Idempotency Nasıl Sağlanır?

Özellikle ödeme, para transferi ve sipariş gibi kritik POST operasyonlarında idempotency sağlamak için sektörün altın standardı Idempotency Key (Benzersiz İşlem Anahtarı)mekanizmasıdır:

1.    İstemci Tarafında Benzersiz Anahtar Üretimi: Mobil uygulama veya web arayüzü, ödeme formu açıldığı an bir benzersiz kimlik (UUID) üretir ve isteğin başlığına (Header) ekler: Idempotency-Key: 7b8f-4a21-9c8e.

2.    Kilit ve Kayıt Kontrolü (Atomic Lock): Sunucu isteği aldığında Redis veya veritabanında bu anahtara bakar.

•  Anahtar ilk kez geliyorsa: İşlem başlatılır, durum "İŞLENİYOR" olarak kilitlenir, sipariş tamamlanır ve sonuç (örneğin sipariş numarası) bu anahtarla birlikte önbelleğe kaydedilir.
• Anahtar zaten mevcutsa: Sunucu bankaya veya veritabanına asla gitmez. Daha önce kaydettiği aynı başarılı yanıtı istemciye anında geri döner.

3.    Veritabanı Seviyesinde Güvence (Unique Constraints): Dağıtık yarış durumlarını (Race Condition) önlemek için veritabanında order_id veya idempotency_key sütununa tekillik kısıtı (UNIQUE INDEX) konulur. İki istek milisaniyelik farkla aynı anda gelse bile veritabanı ikincisini doğrudan reddeder.

Stripe, PayPal veya AWS gibi küresel devlerin API dokümantasyonlarını açtığınızda ilk karşılaşacağınız kavramlardan birinin Idempotency olması tesadüf değildir. Dağıtık mimarilerde ağın kopabileceğini, isteklerin gecikebileceğini veya tekrarlanabileceğini baştan kabullenip sistemleri her tekrarı olgunlukla göğüsleyecek şekilde tasarlamak, profesyonel bir yazılım mimarisinin en temel omurgasıdır.