Bir kullanıcı mobil uygulamada "Poliçeleştir" düğmesine basar, ekran birkaç saniye cevap vermez ve kullanıcı tekrar basar. Ya da bağlantı tam istek giderken kopar, uygulama otomatik olarak yeniden dener. Sunucu tarafında bu iki istek birbirinden habersiz işlenirse aynı müşteri için iki poliçe kaydı, iki tahsilat satırı veya iki ayrı teklif dosyası oluşur. Bu sorunun adı mükerrer işlemdir; çözümünün adı ise idempotency, yani aynı işlemin birden fazla kez uygulanmasının tek bir kez uygulanmasıyla aynı sonucu vermesidir.
Neden yalnızca arayüzde önlem yetmez?
İlk akla gelen çözüm, düğmeye basıldıktan sonra düğmeyi devre dışı bırakmaktır. Bu iyi bir kullanıcı deneyimi uygulamasıdır ama tek başına yeterli değildir. Çünkü mükerrer isteklerin önemli bir kısmı kullanıcıdan değil altyapıdan gelir:
- Mobil cihaz Wi-Fi'dan hücresel ağa geçerken isteği yeniden gönderebilir.
- Yük dengeleyici, yanıt vermeyen bir sunucuya gönderdiği isteği başka bir sunucuya aktarabilir.
- İstemci kütüphaneleri zaman aşımında otomatik yeniden deneme yapabilir.
- Kullanıcı aynı ekranı iki sekmede açmış olabilir.
Bu durumların hiçbirinde arayüzdeki devre dışı düğme işe yaramaz. Güvenilir koruma sunucu tarafında kurulmalıdır.
Idempotency anahtarı nasıl çalışır?
Yöntemin özü basittir. İstemci, durum değiştiren her önemli istekle birlikte benzersiz bir anahtar gönderir. Bu anahtar genellikle istemcide üretilen rastgele bir UUID'dir ve bir HTTP başlığında taşınır. Sunucu isteği aldığında şu adımları izler:
- Anahtarı, ilgili kullanıcı veya acente kapsamında daha önce görüp görmediğini kontrol eder.
- Görmediyse anahtarı "işleniyor" durumuyla kaydeder ve işi yürütür.
- İş bittiğinde sonucu ve yanıt kodunu anahtarla birlikte saklar.
- Aynı anahtar yeniden gelirse işi tekrar yapmaz; saklanan yanıtı aynen döner.
- Anahtar hâlâ "işleniyor" durumundaysa, istemciye işlemin sürdüğünü bildiren bir yanıt verir.
Böylece istemci, yanıtı alamadığı her durumda aynı anahtarla gönül rahatlığıyla yeniden deneyebilir. Sonuç ya ilk isteğin sonucudur ya da işlemin sürdüğü bilgisidir; asla ikinci bir kayıt değildir.
Anahtar ile istek gövdesini eşleştirmek
Aynı anahtarın farklı bir gövdeyle gelmesi de bir hata işaretidir. Örneğin istemci yanlışlıkla eski anahtarı başka bir müşterinin poliçeleştirme isteğinde kullanmış olabilir. Sunucu, ilk istekteki gövdenin özetini de saklamalı ve aynı anahtarla farklı içerik gelirse isteği açık bir hata mesajıyla reddetmelidir. Sessizce eski yanıtı dönmek, kullanıcıyı yanlış bir sonuca inandırır.
Hangi işlemler idempotent olmalı?
HTTP standardında GET, PUT ve DELETE istekleri doğası gereği idempotent kabul edilir. Sorun çoğunlukla yeni kayıt oluşturan POST isteklerindedir. Acente yazılımında öncelik verilmesi gereken işlemler şunlardır:
- Poliçeleştirme: Sigorta şirketi tarafında da kayıt oluşturduğu için mükerrer işlem en pahalı hataya dönüşür.
- Tahsilat kaydı: Muhasebe tutarlılığı doğrudan etkilenir.
- Teklif başlatma: Trafik, kasko ve DASK sorguları ayrı akışlarda yürüdüğünden her branşın sorgu başlatma isteği kendi anahtarını taşımalıdır. Tek bir anahtarı birden fazla branş sorgusunda paylaşmak, birinin sonucunun diğerine dönmesine yol açabilir.
- Müşteri oluşturma: Mükerrer müşteri kartları sonradan temizlenmesi zor bir veri kirliliği yaratır.
Dış servislere giden çağrılarda idempotency
Sorun yalnızca acente yazılımına gelen isteklerle sınırlı değildir. Yazılım, sigorta şirketi servislerine istek gönderirken de aynı riski taşır. Bir poliçeleştirme isteği gönderildikten sonra yanıt gelmeden bağlantı koparsa, işlemin şirket tarafında gerçekleşip gerçekleşmediği belirsiz kalır. Bu durumda körü körüne yeniden denemek yerine:
- Karşı servis bir referans numarası veya istek kimliği destekliyorsa her denemede aynı değer gönderilir.
- Desteklemiyorsa yeniden denemeden önce bir durum sorgusu yapılır.
- Durum hâlâ belirsizse kayıt "doğrulama bekliyor" olarak işaretlenir ve kullanıcıya açıkça gösterilir.
Belirsiz durumu gizlemek yerine görünür kılmak, operasyon ekibinin yanlış varsayımla ikinci bir işlem başlatmasını önler.
Eşzamanlı aynı anahtar: Yarış durumu
En zor senaryo, aynı anahtarlı iki isteğin milisaniyeler arayla iki farklı sunucuya ulaşmasıdır. İki sunucu da anahtarı kontrol eder, ikisi de "görmedim" sonucunu alır ve işi başlatır. Bu yarış durumunu önlemek için anahtar kaydı, veritabanında benzersizlik kısıtı olan bir alana atomik olarak yazılmalıdır. Kaydı ilk yazan sunucu işi yürütür; ikinci sunucu kısıt hatası alır ve işlemin sürdüğünü bildiren yanıtı döner. Kontrol ile yazmanın ayrı adımlar olarak yapılması, korumayı tam da en çok ihtiyaç duyulan anda etkisiz bırakır.
Anahtarın kapsamını doğru belirlemek
Çok kiracılı bir platformda idempotency anahtarı yalnız başına değil, acente ve kullanıcı kimliğiyle birlikte değerlendirilmelidir. İki farklı acentenin istemcisi teorik olarak aynı anahtarı üretse bile birbirlerinin yanıtlarını görmemelidir. Anahtarı acente kimliğiyle birleştirerek saklamak hem güvenlik hem de veri izolasyonu açısından gereklidir. Ayrıca anahtar üretimi istemcinin sorumluluğundadır; tahmin edilebilir sıralı numaralar yerine kriptografik olarak rastgele değerler kullanılmalıdır.
Saklama süresi ve depolama tercihi
Idempotency kayıtları sonsuza kadar tutulmaz. Saklama süresi, istemcinin makul olarak yeniden deneyebileceği süreyi karşılamalıdır. Hızlı erişim için anahtar-değer tabanlı bir önbellek kullanılabilir; ancak poliçeleştirme gibi kritik işlemlerde anahtarın işlemle aynı veritabanı işlemi içinde yazılması daha güvenlidir. Aksi halde iş tamamlanıp anahtar yazılamadan sunucu kapanırsa koruma boşa çıkar.
Kullanıcıya nasıl yansır?
İyi kurgulanmış bir idempotency yapısı kullanıcı tarafından fark edilmez; zaten amacı da budur. Kullanıcı düğmeye iki kez bastığında tek bir poliçe görür, bağlantı koptuğunda uygulama sessizce tekrar dener ve doğru sonucu gösterir. InsureHub'ın mobil sigorta uygulaması ve web paneli gibi aynı veriye farklı cihazlardan erişilen yapılarda bu koruma, sigorta acentesi yazılımı içindeki kayıtların güvenilirliğinin temel taşlarından biridir.
Kendi sisteminizde bir kontrol yapmak isterseniz test ortamında aynı poliçeleştirme isteğini aynı anahtarla art arda iki kez gönderin. Tek bir kayıt ve iki aynı yanıt görüyorsanız temel koruma yerindedir. Ardından aynı anahtarı farklı bir gövdeyle deneyin; sistemin bu kez isteği reddetmesi gerekir.