Idempotency, transaction, timeout, circuit breaker, confirmation gate, compensation ve audit trail

Bir sözleşme yönetim sistemi, yaklaşan yenileme tarihini fark ediyor. Yapay zekâ ajanı şu görevi öneriyor: ‘Yenileme kararını değerlendir’, sorumlu grup ‘Hukuk Operasyon’, son tarih ise fesih bildirim süresinden on gün önce.

Model, görev_olustur adlı işlev için geçerli argümanları üretiyor. Uygulama çağrıyı gönderiyor; ekranda bir süre bekleniyor ve zaman aşımı mesajı görülüyor. Ajan işlemin başarısız olduğunu varsayıp aynı çağrıyı yeniden yapıyor. Kullanıcı birkaç dakika sonra görev listesini açtığında aynı sözleşme için iki görev görüyor.

Sorun modelin görevi yanlış anlaması değildir. Sorun, doğru niyetin güvenli bir işleme dönüştürülememesidir. İlk çağrıda görev oluşmuş, fakat cevap geri dönememiştir. İkinci çağrı ise sistemi aynı etkiyi yeniden üretmeye zorlamıştır.

Bir çağrının cevabını alamamak, işlemin yapılmadığı anlamına gelmez.

Bir önceki DERİNLEŞME bölümünde yapılandırılmış çıktı ve function calling ile modelin güvenilir argüman üretmesini incelemiştik. Bu bölümde aynı görevi bir adım ileri taşıyoruz: Modelin önerdiği işlev çağrısının gerçek kurumsal işleme dönüşmesini, mükerrer etkinin önlenmesini ve hata anında sistemin ne yapması gerektiğini tek bir görev oluşturma senaryosu üzerinden ele alıyoruz.

İşlev çağrısı işlemin kendisi değildir

Şekil 1. Modelin işlev çağrısı yalnızca yapılandırılmış bir niyettir; gerçek işlem doğrulama, yetki, onay, yürütme ve denetim katmanlarından geçer.

Function calling veya tool calling, modelin uygulamada tanımlı bir aracı hangi argümanlarla kullanmak istediğini bildirmesidir. OpenAI dokümantasyonundaki akışta model araç çağrısını üretir; uygulama bu çağrıyı alır, kendi kodunu çalıştırır ve sonucu tekrar modele iletir. Başka bir ifadeyle model ‘ne yapılabileceğini’ söyler; işlemi yapan ve sorumluluğu taşıyan uygulamadır (OpenAI, 2026).

gorev_olustur({

  “sozlesme_id”: “SZL-2026-1842”,

  “baslik”: “Yenileme kararını değerlendir”,

  “grup”: “Hukuk Operasyon”,

  “son_tarih”: “2026-11-20”,

  “kaynak”: “Madde 12 — Fesih ve Yenileme”

})

Bu JSON doğru olabilir; fakat şu sorular hâlâ cevapsızdır: Kullanıcının görev açma yetkisi var mı? Aynı görev daha önce açıldı mı? Tarih iş kuralına uyuyor mu? İnsan onayı gerekli mi? Veritabanına yazma tamamlandı mı? Dış bildirim başarısız olursa ne yapılacak? Bu sorular model katmanının değil, işlem mimarisinin sorularıdır.

Yedi kavram aynı güvenlik zincirinde farklı işler yapar

Kavram	Cevapladığı soru	Görev örneğindeki işi
Idempotency	Aynı istek tekrar gelirse?	İkinci görev yerine ilk sonucun dönmesi
Transaction	Yerel adımlardan biri bozulursa?	Görev, atama ve kayıtların birlikte tamamlanması
Timeout	Belirlenen sürede cevap gelmezse?	Sonucun başarısız değil, belirsiz kabul edilmesi
Circuit breaker	Bağımlı servis sürekli hata verirse?	Yeni çağrıların geçici olarak kesilmesi
Confirmation gate	Kritik işlem çalışmadan kim onaylar?	Görevin grup ve tarihinin insan onayından geçmesi
Compensation	Dağıtık sürecin yarısı tamamlandıysa?	Atamayı geri alma veya görevi iptal durumuna çekme
Audit trail	Ne, kim tarafından, neden yapıldı?	Niyet, onay, deneme ve sonucun kanıtlanması

Bu mekanizmalar birbirinin alternatifi değildir. Idempotency mükerrer etkiyi önler ama yarım kalan yerel kayıtları tek başına düzeltmez. Transaction yerel bütünlüğü sağlar ama e-posta servisini geri alamaz. Audit trail olan biteni gösterir ama hatayı önlemez. Güvenilirlik, bu katmanların birlikte tasarlanmasından doğar.

Timeout: başarısızlık değil, bilinmeyen sonuç

Şekil 2. Zaman aşımından sonra aynı isteği yeni bir işlem gibi göndermek mükerrer görev oluşturabilir. Sabit idempotency anahtarı ikinci isteği ilk sonuçla ilişkilendirir.

Timeout (zaman aşımı), çağıran tarafın belirli süre içinde cevap alamamasıdır. Bu durum üç farklı gerçeği saklayabilir: İşlem hiç başlamamış olabilir, hâlâ çalışıyor olabilir veya tamamlanmış fakat cevap ağda kaybolmuş olabilir. Bu nedenle timeout, ‘başarısız’ değil ‘sonucu bilinmiyor’ durumudur.

AWS Builders’ Library, dağıtık sistemlerde zaman aşımından sonra güvenli retry için API’lerin idempotent tasarlanmasını önerir. Aksi hâlde istemci aynı işlemi tekrar ederek istenmeyen yan etkiler üretebilir. Ayrıca yeniden denemeler artan bekleme süresi ve rastlantısal gecikmeyle sınırlandırılmalıdır; çünkü çok sayıda istemcinin aynı anda retry yapması arızayı büyütebilir (AWS, 2019a; AWS, 2019b).

Idempotency: aynı niyet, tek etki

Idempotency (yinelenebilir işlem güvenliği), aynı mantıksal isteğin birden fazla kez alınması durumunda sistemin tek bir iş etkisi oluşturmasıdır. Kullanıcı aynı düğmeye iki kez basabilir, ağ katmanı isteği tekrar iletebilir veya ajan timeout sonrasında retry yapabilir. Hepsi aynı niyetin tekrarıysa sonuç tek görev olmalıdır.

Uygulama, ilk çağrıdan önce sabit bir idempotency key üretir. Örneğin kullanıcı işlemi için rastgele bir operation_id oluşturulabilir veya iş anlamı güvenilir biçimde tanımlanabiliyorsa sözleşme kimliği, işlem türü ve dönem gibi alanlar birleştirilebilir. Kritik nokta, retry sırasında aynı anahtarın korunmasıdır.

Idempotency-Key: op_7fa8b1d2

İşlem türü: gorev_olustur

Kaynak: SZL-2026-1842

İstek özeti: sha256(onaylanmış_argümanlar)

İstek kaydında tutulacak alan	Neden gerekli
Idempotency key	Aynı mantıksal işlemi tanımak
İstek özeti / payload hash	Aynı anahtarla farklı içerik gelmesini reddetmek
Durum	İşleniyor, tamamlandı, belirsiz, başarısız ayrımı
Sonuç kimliği	Retry geldiğinde mevcut görev numarasını döndürmek
Oluşturma ve sona erme zamanı	Saklama ve yeniden kullanım politikasını yönetmek
Kullanıcı / ajan kimliği	Yetki ve denetim bağlamını korumak

Aynı anahtar aynı içerikle tekrar gelirse uygulama önceki sonucu döndürür. Aynı anahtar farklı argümanlarla gelirse çağrı reddedilmelidir; aksi hâlde eski onay yeni bir işleme taşınmış olur. Anahtarların ne kadar süre saklanacağı da iş riskine göre belirlenmelidir. Görev, ödeme veya rezervasyon gibi etkiler için birkaç dakikalık kayıt çoğu zaman yeterli değildir.

Retry yeni bir niyet değildir; ilk niyetin güvenli biçimde tamamlanma çabasıdır.

Transaction: ya hep ya hiç

Şekil 3. Tek veritabanındaki kayıtlar transaction ile birlikte tamamlanabilir. Dış servisler aynı sınırda olmadığı için outbox, idempotent tüketim ve telafi gerekir.

Transaction (işlem bütünlüğü), birbiriyle ilişkili veritabanı adımlarını tek bir bütün olarak ele alır. PostgreSQL dokümantasyonunun ifadesiyle çok adımlı bir işlem, diğer oturumlara kısmen görünmeden ya bütünüyle uygulanır ya da hiç uygulanmaz (PostgreSQL, 2026).

Görev oluşturma sırasında görev kaydı yazılıp grup ataması yazılamazsa sistemde sahipsiz bir görev kalmamalıdır. Görev, atama, idempotency sonucu ve dış bildirim için outbox kaydı aynı transaction içinde yazılabilir. Hepsi başarılıysa COMMIT yapılır; biri başarısızsa ROLLBACK ile yerel değişiklikler geri alınır.

Fakat veritabanı transaction’ı e-posta servisini, takvimi veya başka bir uygulamanın API’sini aynı atomik sınır içine alamaz. Bu nedenle dış bildirim, transaction içinde kaydedilen outbox olayından daha sonra gönderilir. Mesaj en az bir kez ulaşabileceği için tüketici tarafı da idempotent olmalıdır. ‘Exactly once’ ifadesi çoğu dağıtık sistemde tek bir sihirli ayar değil; idempotent işlem, tekil kısıt, durum kaydı ve deduplication bileşimidir (Microsoft, 2026a).

Confirmation gate: model önerebilir, yetki uygulamadadır

Confirmation gate (onay kapısı), yan etkili veya riskli işlem çalışmadan önce insanın ya da deterministik bir yetki politikasının açık onay vermesidir. Her görev için insan onayı verimliliği düşürür; hiçbir görev için onay istememek ise model hatasını gerçek işleme dönüştürür. Bu nedenle kapı risk tabanlı olmalıdır.

• Düşük risk: Kişisel yapılacaklar listesine taslak görev ekleme otomatik olabilir.
• Orta risk: Başka bir gruba görev atama, grup yöneticisinin tek tıklık onayını gerektirebilir.
• Yüksek risk: Dış tarafa bildirim, ödeme, fesih veya imza süreci daima yetkili insan onayından geçmelidir.

Onay ekranı yalnızca ‘Onayla’ düğmesi göstermemelidir. Kullanıcı görev başlığını, sorumlu grubu, son tarihi, kaynağı, ajan gerekçesini ve oluşacak yan etkileri görmelidir. Onaydan sonra kritik argüman değişirse eski onay geçersiz sayılmalıdır.

Circuit breaker: arızalı servise yük bindirmeyi durdurmak

Circuit breaker (devre kesici), bağımlı servis sürekli hata verdiğinde yeni çağrıları geçici olarak engeller. Closed durumda çağrılar geçer. Hata eşiği aşılınca devre Open olur ve sistem başarısız olacağı bilinen çağrıları göndermek yerine hızlıca kontrollü hata verir. Belirli süre sonra Half-open durumda sınırlı bir deneme yapılır; servis düzelmişse devre kapanır (Microsoft, 2026b).

Bu mekanizma retry ile aynı değildir. Retry tek bir geçici hatanın düzelebileceğini varsayar. Circuit breaker ise bir süreliğine bağımlılığın sağlıksız olduğunu kabul eder ve bütün çağrıları korur. Görev servisi devre dışıysa ajan yüzlerce retry üretmemeli; işlemi ‘beklemede’ durumuna almalı, kullanıcıya bilgi vermeli ve iyileşme sinyali beklemelidir.

Compensation: geri alma her zaman silmek değildir

Compensation (telafi işlemi), dağıtık bir iş akışında daha önce tamamlanmış adımların iş anlamına uygun biçimde etkisizleştirilmesidir. Microsoft’un Compensating Transaction Pattern’ı, eventual consistency kullanan süreçlerde her adım için geri alma veya düzeltme davranışının açıkça tasarlanmasını önerir; telafi adımları da başarısız olabileceği için idempotent olmalıdır (Microsoft, 2026c).

Örneğin görev oluşturulmuş ve gruba atanmış, fakat kritik bildirim gönderilememiş olabilir. Kurum politikasına göre üç seçenek vardır: Görevi koruyup ‘bildirim bekliyor’ durumuna almak, atamayı geri çekip manuel incelemeye yönlendirmek veya görev kaydını silmek yerine ‘iptal edildi’ olarak işaretlemek. Gönderilmiş bir e-posta geri alınamayacağı için telafi, ikinci bir düzeltme bildirimi göndermek olabilir.

Teknik rollback geçmişi yok eder; iş telafisi geçmişi görünür tutarak sonucu düzeltir.

Audit trail: sonucun değil karar zincirinin kaydı

Şekil 4. İşlem durumları belirsizliği görünür kılar. Timeout sonrası kör retry yerine durum sorgulama, uzlaştırma ve gerektiğinde telafi uygulanır.

Audit trail (denetim izi), işlemin yalnızca sonucunu değil karar ve yürütme zincirini yeniden kurmaya yarayan kayıttır. NIST log yönetimi rehberi; kayıt üretimi, iletimi, saklanması, erişimi ve analizini planlı bir süreç olarak ele alır. Yapay zekâ ajanlarında buna model ve araç bağlamı da eklenmelidir (NIST, 2006).

Denetim alanı	Örnek
Kimlik	Kullanıcı, ajan ve hizmet hesabı
Model bağlamı	Model/sürüm, istem sürümü, araç tanımı
Niyet ve argüman	gorev_olustur + doğrulanmış alanlar
Yetki ve onay	Politika sonucu, onaylayan kişi ve zaman
İşlem kimliği	Idempotency key, transaction ve görev numarası
Yürütme	Deneme sayısı, timeout, circuit breaker durumu
Sonuç	Tamamlandı, belirsiz, telafi edildi veya insan devraldı

Denetim izine kişisel veri, sözleşme sırrı veya erişim anahtarı gelişigüzel yazılmamalıdır. Hangi alanların maskeleneceği, kimlerin loglara erişeceği, kayıtların ne kadar saklanacağı ve değiştirilmeye karşı nasıl korunacağı veri sınıflandırma politikasıyla belirlenmelidir.

Senaryoyu uçtan uca güvenli kuralım

1. Ajan sözleşmedeki yenileme ve fesih maddesini kaynak kesitiyle birlikte analiz eder.
2. Model gorev_olustur işlevini ve şemaya uygun argümanları önerir; henüz işlem yapılmaz.
3. Uygulama şema, tarih, mükerrer iş kuralı, kullanıcı rolü ve veri kapsamını doğrular.
4. Başka gruba atama nedeniyle onay kapısı açılır; insan görev ve yan etkileri görerek onay verir.
5. Uygulama tek bir operation_id/idempotency key üretir ve onaylanmış argüman özetiyle kaydeder.
6. Transaction içinde görev, grup ataması, idempotency sonucu, audit kaydı ve outbox olayı yazılır.
7. Cevap timeout’a uğrarsa durum ‘sonuç belirsiz’ olur; aynı anahtarla sorgu veya retry yapılır.
8. Görev daha önce oluşmuşsa ikinci kayıt açılmaz; mevcut görev numarası döndürülür.
9. Bildirim servisi arızalıysa circuit breaker çağrıları keser; outbox kaydı daha sonra yeniden işlenir.
10. Kritik yan etki tamamlanamazsa tanımlı telafi çalışır veya işlem yetkili insana devredilir.

Şeytanın avukatlığı: her önlem yeni bir karmaşıklık getirir

Idempotency kayıtları depolama ve yaşam süresi yönetimi ister. Onay kapıları hız kazanımını azaltabilir. Circuit breaker yanlış eşikle sağlıklı servisi gereksiz yere kapatabilir. Compensation, basit rollback gibi görünse de iş kurallarını kodlamayı gerektirir. Ayrıntılı audit trail ise mahremiyet ve güvenlik riskine dönüşebilir.

Bu itirazlar doğrudur; fakat sonuç ‘bu kontrolleri kaldırmak’ değildir. Kontrol seviyesini işlemin etkisine göre ayarlamaktır. Bir taslak not ile sözleşme feshi aynı mimariyle yönetilmemelidir. Kurumların amacı her ajanı ağır bir bürokrasiye bağlamak değil, olası zararla orantılı güvence kurmaktır.

Sık yapılan yanlış varsayımlar

• ‘Timeout olduysa işlem yapılmamıştır.’ Yanlış: İşlem tamamlanmış, cevap kaybolmuş olabilir.
• ‘Aynı isteği tekrar göndermek güvenlidir.’ Yalnızca işlem gerçekten idempotent tasarlanmışsa.
• ‘Transaction bütün süreci geri alır.’ Yalnızca kapsadığı kaynaklarda; dış servisler ayrıca yönetilir.
• ‘Onay aldıysak argümanlar sonradan değişebilir.’ Kritik içerik değişirse onay yeniden alınmalıdır.
• ‘Audit log varsa sistem güvenlidir.’ Log kanıt sağlar; yetki, önleme ve iyileştirme mekanizması değildir.
• ‘Exactly once teslimat üründe hazır bir özelliktir.’ Uçtan uca tek etki genellikle deduplication ve idempotent tüketimle inşa edilir.

İş birimlerinin sorabileceği on kontrol sorusu

• Ajanın önerdiği işlev ile işlemi gerçekten çalıştıran bileşen birbirinden ayrılmış mı?
• Her yan etkili işlem için sabit bir idempotency anahtarı üretiliyor mu?
• Aynı anahtar farklı içerikle gelirse sistem isteği reddediyor mu?
• Timeout sonrası sonuç ‘başarısız’ yerine ‘belirsiz’ olarak yönetilebiliyor mu?
• Görev, atama ve denetim kayıtları uygun transaction sınırında mı?
• Dış servis çağrıları outbox, idempotent tüketim veya benzeri mekanizmalarla korunuyor mu?
• Retry sayısı, bekleme aralığı ve circuit breaker eşikleri tanımlı mı?
• Riskli görevler için onaylayan kişi oluşacak yan etkileri görebiliyor mu?
• Her dış adım için uygulanabilir telafi veya insan devralma yolu var mı?
• Denetim izi karar zincirini açıklarken hassas veriyi de koruyor mu?

Kısa kavram sözlüğü

Idempotency — yinelenebilir işlem güvenliği: Aynı mantıksal isteğin tekrarında tek iş etkisi oluşturma özelliği.

Transaction — işlem bütünlüğü: İlişkili yerel adımları ya hep ya hiç ilkesiyle tamamlama.

Timeout — zaman aşımı: Belirlenen sürede cevap alınamaması; işlemin sonucunun bilinmediği durum.

Circuit breaker — devre kesici: Arızalı bağımlılığa çağrıları geçici olarak durduran koruma deseni.

Confirmation gate — onay kapısı: Yan etkili işlem öncesinde yetkili insan veya politikanın açık onayı.

Compensation — telafi işlemi: Tamamlanmış dağıtık adımların iş anlamına uygun biçimde etkisizleştirilmesi veya düzeltilmesi.

Audit trail — denetim izi: Niyet, yetki, onay, yürütme ve sonucu yeniden kurmaya yarayan değişmez kayıt zinciri.

Transactional outbox — işlemsel giden kutusu: Veri değişikliğiyle dışarı gönderilecek olayı aynı transaction içinde kaydetme deseni.

Sonuç: ajanın zekâsı kadar işlem disiplini de önemlidir

Bir yapay zekâ ajanını gerçek iş ortamına almak, modele birkaç araç tanımlamaktan ibaret değildir. Model doğru işlevi ve doğru argümanları seçse bile ağ, veri tabanı, yetki, onay ve dış servisler yeni hata ihtimalleri üretir.

Güvenilir mimari; timeout’u belirsiz sonuç olarak yönetir, retry’ı aynı idempotency anahtarıyla yapar, yerel değişiklikleri transaction içinde toplar, arızalı bağımlılığı circuit breaker ile sınırlar, riskli işlemi onay kapısından geçirir, dağıtık hatayı telafi eder ve bütün karar zincirini denetim izinde korur.

Yapay zekâ ne yapılacağını önerebilir; aynı işin yalnızca bir kez ve doğru yetkiyle yapılmasını sistem mimarisi güvence altına alır.

Bir sonraki DERİNLEŞME bölümünde

“Bir yapay zekâ ajanı yarım kalan bir işi nasıl hatırlar ve güvenle nasıl devam ettirir?”

DERİNLEŞME 16’da state machine (durum makinesi), checkpoint (kontrol noktası), durable execution (kalıcı yürütme), retry policy (yeniden deneme politikası), dead-letter queue (hatalı ileti kuyruğu), reconciliation (uzlaştırma) ve human takeover (insan devralması) kavramlarını yarıda kesilen bir sözleşme iş akışı üzerinden inceleyeceğiz.

Yazar

Dr. Mert Dönerçark

Yapay Zekâ Araştırmacısı ve Yazılım Stratejisti

Yayın Destekçisi ve Şeffaflık Notu

Bu yayın, MicroDestek katkılarıyla hazırlanmaktadır. Yazılarımda zaman zaman örneklerine yer verdiğim KolayOfis, ContractFlow ve MicroDestek Yapay Zekâ Asistanı, görev yaptığım MicroDestek tarafından geliştirilmektedir. Paylaştığım değerlendirmeler ise akademik ve uygulamalı çalışmalarım doğrultusunda oluşturulmuş kişisel görüşlerimi yansıtmaktadır.

Kaynakça

• Amazon Web Services. (2019a). Making retries safe with idempotent APIs. AWS Builders’ Library. Bağlantı
• Amazon Web Services. (2019b). Timeouts, retries, and backoff with jitter. AWS Builders’ Library. Bağlantı
• Microsoft. (2026a). Transactional Outbox pattern. Azure Architecture Center. Bağlantı
• Microsoft. (2026b). Circuit Breaker pattern. Azure Architecture Center. Bağlantı
• Microsoft. (2026c). Compensating Transaction pattern. Azure Architecture Center. Bağlantı
• National Institute of Standards and Technology. (2006). Guide to Computer Security Log Management (SP 800-92). Bağlantı
• OpenAI. (2026). Function calling. OpenAI API documentation. Bağlantı
• PostgreSQL Global Development Group. (2026). Transactions. PostgreSQL documentation. Bağlantı