DEV Community: Hüseyin Bozdemir

Ön provizyon nedir, kart neden bloke edilir?

Hüseyin Bozdemir — Thu, 12 Nov 2026 08:21:26 +0000

Online marketten kiloyla satılan ürünler sipariş etmiştim. Sepet tutarı belliydi ama kartımda ondan fazlası bloke edilmiş görünüyordu. Fazlası ertesi gün geri geldi.

Bunun adı ön provizyon (pre-authorization). İşyeri son tutarı henüz bilmiyorsa kartından tahmini bir tutarı bloke ettirir, kesin tutarı sonradan ayrı bir işlemle çeker. Aradaki fark kartına geri döner. 500 ₺'lik bir sepette 600 ₺ bloke edilir, ürünler tartılınca 540 ₺ çekilir, kalan 60 ₺ serbest kalır.

Bu akışı sanal POS entegrasyonlarında ben de yazdım. Kullananlar çoğunlukla akaryakıt işyerleri ve kiloyla satış yapan gıda işyerleriydi.

Tutar neden baştan bilinmiyor?

Çoğu alışverişte tutar ödeme anında bellidir. İşyeri bankaya sorar, onay gelir, para çekilir. Bazı satışlarda ise fiyat ödemeden sonra kesinleşir.

Tartılı üründe bir kilo domates istersin, poşete 1.080 gram girer. Fiyat tartıdan sonra belli olur, tartı da sen ödemeyi yaptıktan sonra yapılır.

Akaryakıtta pompa, kaç liralık yakıt alacağını dolum bitene kadar bilmez. Kart çıkaran tarafın gözünden bu akışı Stripe'ın dokümanı anlatıyor: pompa önce küçük bir tutarla kartı sorar, banka bilinmeyen tutarı karşılamak için daha yüksek bir tutarı ayırır, dolum bitince gerçek tutar bildirilir. Oradaki rakamlar ABD'ye göre, akış aynı.

Otelde ve araç kiralamada da durum benzer. Minibar, ek gece ya da hasar çıkışta belli olur. Otel konaklama sürerken ek provizyon da isteyebilir.

Üçünde de işyeri parayı garantiye almak ister ama ne kadar olacağını bilmez. O yüzden biraz fazlasını ayırtır.

Bloke ve tahsilat ayrı işlemler

Ön provizyonda banka parayı işyerine göndermez. Yalnızca kartının kullanılabilir tutarından o kadarını ayırır. Sanal POS dokümanlarında bu işlem tipi PreAuth diye geçer. Para, işyeri ikinci işlemi gönderince hareket eder. Onun adı provizyon kapama (PostAuth, İngilizce kaynaklarda capture).

Sipariş anında banka 600 ₺'yi ayırır ama işyerine göndermez. Ürünler tartılınca işyeri 540 ₺ için kapama gönderir; kalan 60 ₺ kartın kullanılabilir tutarına geri döner.

Bizim yazdığımız akışta kapama, ürün tartıldıktan sonra kilo hesabından çıkan net tutarla gönderiliyordu.

Blokenin baştan yüksek tutulmasının sebebi de kapama. İşyeri ayırttığından fazlasını çekmeye kalkarsa sorun çıkar: Visa'nın duyurusunda provizyondan yüksek tutarla işlenen işlem, kartın bankasının itiraz edebileceği durumlar arasında sayılıyor. Ürün ağır gelirse diye pay baştan bırakılır.

Kartın türü burada fark ediyor. Kredi kartında bloke limitini düşürür. Banka kartında ise hesaptaki paranın kendisi ayrılır, fazla bloke o yüzden daha çok can yakar.

Fark ne zaman geri gelir?

En olağan yol kapamanın gelmesi. İşyeri gerçek tutarı gönderir, banka onu çeker ve kalanını bırakır. Benim siparişimde bu ertesi gün oldu.

İkinci yol kısmi iptal (partial reversal). İşyeri kapamayı beklemeden "şu kadarına ihtiyacım kalmadı" der ve fazla tutar hemen serbest kalır.

İkisi de gelmezse bloke, süresi dolana kadar durur. Bu süre için elimdeki tek birinci el kaynak Visa'nın ABD'deki üye işyeri bankalarına yazdığı duyuru. Ona göre Nisan 2024'ten beri pompadaki ön provizyon için iki saat içinde kapama ya da iptal gönderilmesi gerekiyor. Tahmini tutarla alınan otel ve araç kiralama provizyonlarında süre 30 gün, kart sahibinin başlattığı internet alışverişinde 10 gün.

Türkiye'deki bankalar için böyle bir belge bulamadım. Baktığım bir banka rehberi bekleyen ödemenin karta 1-3 iş günü içinde yansıdığını, sorun çıkarsa bunun bir haftayı bulabildiğini yazıyor. Kapaması hiç gelmeyen bir ön provizyonun ne zaman düşeceğini yazmıyor.

Kapama hiç gelmezse

Açık kalan ön provizyonların çoğu teknik bir hatadan kalmıyordu. İşyeri kapamayı göndermeyi unutuyordu.

O durumda blokeyi banka kendisi iptal ediyordu. Ne zaman iptal edeceği bankadan bankaya değişiyordu, kabaca bir ayı buluyordu.

Kart sahibi için bu, bir ay boyunca kullanamadığı bir para demek. İşyeri de kazançlı çıkmıyor. Kapama gitmediyse para da alınmamıştır ve süre dolduktan sonra o provizyonla tahsilat yapılamaz.

Biz ödemelerin akıbetini bankadan sürekli sorguluyorduk. Banka bir ön provizyonu iptale aldıysa bunu sorgudan görüyor, kaydı kendi tarafımızda da otomatik olarak iptale çekiyorduk. Böylece bizdeki durum bankadakiyle aynı kalıyordu. Ne zaman iptale düşeceği yine bankaya göre değişiyordu.

Entegrasyonu sen yazıyorsan açık ön provizyonu "bir gün kapanır" diye bırakma. Durumunu bankaya sor ve kendi kaydını ona göre güncelle. Yoksa banka blokeyi çoktan bırakmışken senin sisteminde o ödeme hâlâ bekliyor görünür.

Paran bloke kaldıysa

Önce bankanın uygulamasında bekleyen işlemlere bak. Tutar orada "provizyon" ya da "bekleyen" diye duruyorsa henüz çekilmemiştir.

Sonra işyerine yaz. Kapamayı da iptali de onlar gönderir, banka kendiliğinden ancak süre dolunca bırakır. İşyeri iptal ettiğini söylüyor ama bloke hâlâ duruyorsa sıra bankada.

Benzer bir bekleme çevrimdışı kart ödemesinde de var. Orada onay sonradan gelir, burada tutar.

Bu yazı ilk olarak huseyinbozdemir.com'da yayımlandı: https://huseyinbozdemir.com/blog/on-provizyon-nedir

Claude Fable 5.2 nedir? Fiyat, limit, farklar

Hüseyin Bozdemir — Tue, 10 Nov 2026 20:14:26 +0000

9 Kasım 2026'da Anthropic iki modeli birlikte yayımladı: Claude Fable 5.2 ve Claude Mythos 5.2. Fable 5.2, Anthropic'in herkese açık en yetenekli modeli; saatlerce süren ajan işleri ve zor akıl yürütme için konumlanıyor. Duyuru benchmark tablolarıyla dolu. API'yi kendi kodundan çağırıyorsan asıl okuman gereken sayfa ise geçiş notları.

Çünkü model adını claude-fable-5-1'den claude-fable-5-2'ye çevirmek her zaman yetmiyor. Dört değişiklik çalışan kodu bozabiliyor.

Fable 5.2 ile Mythos 5.2 arasındaki fark ne?

İkisi aynı model. Fark önlerindeki güvenlik katmanında: Fable'da siber güvenlik ve biyoloji için sınıflandırıcılar çalışıyor. Mythos bu korumaların bir kısmı olmadan, yalnızca Anthropic'in doğrulama programlarından geçmiş kuruluşlara açık. Fiyat ve teknik özellikler aynı: 1 milyon token bağlam, 128 bin token çıktı.

Duyuruya göre Fable'ın sınıflandırıcıları sızma testi, exploit üretimi ve derlenmiş dosya üzerinden zafiyet analizi gibi işleri engelliyor. Engellenen sorguya siber güvenlikte Opus 4.8, biyolojide Opus 5 cevap veriyor. Anthropic, Fable 5.1'e göre engellemelerin yaklaşık %55 azaldığını söylüyor.

Ret, HTTP 200 ve stop_reason: "refusal" ile gelir. Claude uygulamalarında başka modele düşme kendiliğinden olur; API'de yeniden denemeyi sen açarsın.

Duyuruda alışılmadık bir ayrıntı daha var. Anthropic, eğitim sırasında yapay zekâ geliştirmeyi doğrudan hızlandırabilecek araştırma yeteneklerindeki ilerlemeyi bilerek sınırladığını yazıyor. Verdiği örnekler hızlandırıcı (GPU benzeri donanım) kernel optimizasyonu ve dil modeli mimarisini iyileştirme. Bu alanlarda model Opus 5.5 düzeyinde kalıyor.

Fable 5.2 fiyatı ve hızı

Milyon token fiyatı girdide 8, çıktıda 40 dolar. Fable 5.1'de 10 ve 50 dolardı.
Çıktı üretimi 5.1'e göre %30'a kadar hızlı.
Fast mode çıktıyı 2,5 kata kadar hızlandırıyor, fiyatı iki katı: 16 ve 80 dolar.

Anthropic'in kendi ailesinde Fable en pahalı katman: Opus 5.5 milyon token başına 4 ve 20, Sonnet 5.5 ise 2 ve 10 dolar. Model seçimi önerisi de buna göre: çoğu işte önce Opus'la başla, Opus yüksek effort'ta bile senin ölçümlerinde yetmiyorsa Fable'a geç.

GPT-6 Astra ve Gemini 4 Carbon ile karşılaştırma

Duyurudaki tablo Fable 5.2'yi bir önceki sürümle, Opus 5.5'le ve iki rakiple yan yana koyuyor: OpenAI'ın GPT-6 Astra'sı ve Google'ın Gemini 4 Carbon'u. Tablonun bir kısmı:

Ölçüm	Fable 5.2	Fable 5.1	Opus 5.5	GPT-6 Astra	Gemini 4 Carbon
FrontierCode 2.0 (ajanla kodlama)	%49,1	%32,4	%45,5	%42,8	%41,1
FrontierSWE v2 (ajanla kodlama)	%69,9	%56,3	%62,3	%65,5	%61,2
AutomationBench (iş akışları)	%51,4	%31,4	%42,5	%41,4	%53,9
OSWorld 2.1 (bilgisayar kullanımı)	%89,3	%83,5	%87,2	%79,5	%81,5
Remote Labor Index (bilgi işi)	%41,3	%17,9	%21,3	%20,8	yok
Humanity's Last Exam (araçlarla)	%74,2	%65,6	%67,7	%57,2	yok
Chartography (grafik okuma)	%73,4	%44,8	%64,4	%71,0	%72,5

Fable 5.2 her satırda birinci değil. AutomationBench'te Gemini 4 Carbon önde, bilgi işini ölçen AA-Briefcase'in Elo sıralamasında da Opus 5.5 (1800) Fable 5.2'nin (1785) üstünde.

Maliyet tarafında öne çıkarılan sonuç FrontierCode 2.0'dan: Fable 5.2 high effort'ta %45,3 alıyor. Bu, Opus 5.5'in en iyi skoruyla (%45,5) neredeyse aynı ve görev başına maliyeti yaklaşık yarısı. Tablodaki %49,1 ise xhigh effort'un sonucu.

Bir not: ölçümlerin hepsini Anthropic yaptı ve modeller aynı ayarda koşmadı (FrontierCode'da Gemini medium, Fable xhigh effort'ta). Bağımsız ölçümler gelene kadar tabloyu şirketin kendi beyanı olarak oku.

Limit sıfırlama (reset) hakkı

Lansmanla birlikte ücretli abonelere "Fable reset" hakkı verildi. Kampanya sayfasına göre kurallar şöyle:

Pro ve Team standart koltuk: 9-16 Kasım arasında haftalık limitin %50'sine kadar Fable kullanımı plana dahil, ayrıca bir reset hakkı var. İkisi de 16 Kasım 23:59'da (Pasifik saati; Türkiye'de 17 Kasım 10:59) bitiyor.
Max, Ultra ve Team premium koltuk: abonelik süresine göre bir ile üç arası reset. 6 aydan kısa abonelikte bir, 6-12 ayda iki, 12 aydan uzunda üç. Son kullanma tarihi 8 Mart 2027.
Kapsam dışı: ücretsiz plan ve kullanım bazlı Enterprise planları.

Reset limiti büyütmüyor, harcananı geri veriyor. Haftalık limitte yalnızca Fable modelleriyle harcadığın kısım geri geliyor. Beş saatlik pencere ise diğer modeller dahil tamamen yenileniyor. Limitin dolmasını beklemen gerekmiyor ama kullandıktan sonra geri alamıyorsun.

Hak kazanmak için 9 Kasım 10:00'dan (Pasifik saati; Türkiye'de 21:00) önce ücretli abone olman gerekiyordu. Reset, Claude'da Ayarlar → Kullanım sayfasındaki "Limit resets" bölümünden "Reset for free" ile kullanılıyor. Sayfanın uyarısı da var: Fable modelleri limiti diğer modellerden daha hızlı tüketiyor.

5.1'den geçerken ne kırılır?

Geçiş notları dört kırıcı değişiklik sayıyor:

Geçmişi düzenleyen kod. Model her düşünme bloğunu (thinking block) kendinden önceki içeriğe bağlıyor: system, tools ve önceki mesajlar. Bloğu geri gönderirken bunlardan biri değişmişse istek 400 dönüyor. Fable 5.1'de bu denetim yalnızca 31 Ağustos 2026 ve sonrasında açılan hesaplarda vardı, 5.2'de her hesapta var.
Konuşma ortasında model değiştirmek. Fable 5.2'nin düşünme bloklarını yalnızca Fable 5.2 ve Mythos 5.2 okuyabiliyor. Konuşmayı Opus 5.5'e ya da 5.1'e taşırsan istek başarılı olur ama o bloklar düşer.
Eski computer use aracı. computer_20251124 Bedrock dışında 400 dönüyor, yerine computer_toolset_20260801 geliyor.
Advisor aracı. Yürüten model Fable 5.2 ise danışman da Fable 5.2 ya da Mythos 5.2 olmak zorunda.

En sinsisi ilki, çünkü eski bir hesapta 5.1 ile sorunsuz çalışan kod model adını değiştirdiğin anda kırılabiliyor. "Geçmişi düzenlemek" de kulağa geldiğinden geniş. Doküman şunları sayıyor: system prompt'a her istekte bugünün tarihini yeniden yazmak, eski araç sonuçlarını kısaltmak, eski turları istemci tarafında özetlemek, tools listesine araç ekleyip çıkarmak. Hata şöyle geliyor:

Invalid `signature` in `thinking` block. The block is bound to a different conversation.

Geçici çıkış beta'daki prefix_mismatch_behavior: "drop_block" ayarı: bozulan bloklar atılır, istek geçer. Bedeli var; model okuyamadığı akıl yürütmeyi yeniden üretir, bu da daha çok çıktı token'ı ve daha uzun yanıt demek. Kalıcı çözüm geçmişe yalnızca ekleme yapmak.

Opus 5 ya da daha eski bir Opus'tan geliyorsan iki kural daha var: düşünme kapatılamıyor, tool_choice ile aracı zorlamak (any ya da tool) 400 dönüyor.

Ret hata değil: HTTP 200 döner

Sınıflandırıcı bir isteği reddettiğinde hata kodu gelmiyor. Yanıt başarılı, içerik boş (dokümandaki örneğin kısaltılmışı):

{
  "content": [],
  "stop_reason": "refusal",
  "stop_details": {
    "type": "refusal",
    "category": "cyber",
    "explanation": "This request was declined because it could enable cyber harm."
  }
}

Bunun iki sonucu var. İzlemen hata oranına ya da 5xx'e bakıyorsa retleri hiç görmez; stop_reason değerini ayrı bir metrik olarak sayman gerekir. İkincisi, API'de başka modele düşme kendiliğinden olmuyor. Ya fallbacks parametresini (beta) açarsın, ya SDK'nın hazır ara katmanını kullanırsın, ya da yeniden denemeyi kendin yazarsın. Fable 5.2 için izin verilen hedefler Opus 4.8 ve Opus 5.

Zararsız iş de takılabiliyor. Dokümandaki kategori tablosu bunu açıkça yazıyor: iyi niyetli bir güvenlik çalışması cyber, sıradan bir makine öğrenmesi işi frontier_llm reddi alabilir. Prompt'unda modelden akıl yürütmesini çıktıya yazmasını istiyorsan (bir <thinking> bölümü, JSON'da reasoning alanı) o da reasoning_extraction reddine yol açıyor. Bu kategorinin fallback'i yok, prompt'u değiştirmen gerekiyor.

Geçmeden önce neye bakmalı?

messages dizisini kendi kodun mu kuruyor? Öyleyse geçmişe dokunan her yeri bul: tarih, özetleme, araç sonucu kırpma.
Konuşma ortasında model değiştiren bir router ya da fallback var mı?
stop_reason: "refusal" log'da ve metriklerde ayrı görünüyor mu?
Ölçümlerini high effort'tan başlayarak yeniden koştur. Aynı işi Opus 5.5 daha ucuza yapıyor olabilir.

İstekleri Claude Code, claude.ai ya da Agent SDK kuruyorsa ilk iki maddeyle uğraşmana gerek yok.

Bu yazı ilk olarak huseyinbozdemir.com'da yayımlandı.

Loop engineering nedir, her işe değer mi?

Hüseyin Bozdemir — Tue, 10 Nov 2026 20:14:07 +0000

Prod'a doğrudan çıkmayacak hemen her işi yapay zekâya yaptırıyorum. Önce mimari incelemesini yaptırıyorum, sonra çıktıyı kendim inceliyorum, uygunsa prod'a gönderiyorum.

Bu akışta işi yine ben başlatıyorum ve sonucu yine ben okuyorum. Bu yıl çok konuşulan loop engineering ise aradaki adımların büyük kısmını ajanın çevresine kurulan bir sisteme devretmeyi anlatıyor. Türkçe kaynağı az olduğu için önce kavramı netleştireyim, sonra sınırı nereye koyduğumu anlatayım.

Loop engineering nedir?

Loop engineering (döngü mühendisliği), yapay zekâ ajanına her adımı tek tek söylemek yerine onu çalıştıran, sonucunu kontrol eden ve gerekirse yeniden çalıştıran sistemi tasarlamaktır. Terim Haziran 2026'da yayıldı. Sık anılan metinlerden biri Addy Osmani'nin 7 Haziran tarihli yazısı.

Osmani'nin örneği konuyu iyi anlatıyor. Her sabah bir otomasyon CI hatalarını ve açık issue'ları okuyor. Uygun bulduğu iş için ayrı bir çalışma kopyası (worktree) açılıyor, bir ajan düzeltmeyi hazırlıyor, ikinci bir ajan da onu inceliyor. Geliştirici bu adımları tek tek istemiyor.

Alışkın olduğumuz akışta prompt yazar, çıktıyı okur ve sıradaki adımı yine sen yazarsın. Döngüde bu turu bir sistem döndürür. Kabaca şöyle görünür:

hedef: bütün testler geçsin
tur sınırı: 5

her turda:
  ajan işi yapar
  testler çalışır
  geçtiyse: dur, insana gönder
  geçmediyse: hatayı ajana ver

sınır dolduysa: dur, haber ver

Terim, "agent loop" ile sık karıştırılıyor. Google'ın sözlüğü agent döngüsünü, ajanın bir sonlandırma koşulu karşılanana kadar tekrar tekrar ilerlediği döngü olarak tanımlıyor. Yani agent loop ajanın kendi çalışma turu. Loop engineering ise bu turların ne zaman başlayacağını, nasıl kontrol edileceğini ve ne zaman duracağını tasarlama işi.

Kavramın yeni olup olmadığı da tartışılıyor. HackerNoon'daki bir yazı bunun Kent Beck'in kırmızı, yeşil, refactor döngüsünün ajana devredilmiş hali olduğunu savunuyor. Benzerlik gerçek: ikisinde de işi döndüren şey, geçip geçmediği ölçülebilen bir hedef.

Prompt, context, harness ve loop farkı

Bu dört terim sık sık birbirine karışıyor. Machine Learning Mastery'nin girişi bunları iç içe katmanlar olarak sıralıyor. Her katman öncekini içeriyor, yerine geçmiyor.

Katman	Neyi tasarlarsın?	Örnek
Prompt	Modele verdiğin talimatın kendisini	"Bu metodu sadeleştir"
Context	Modelin yanıt verirken gördüğü her şeyi	Konuşma geçmişi, belgeler, araç çıktıları
Harness	Ajanın içinde çalıştığı düzeni	Kural dosyaları, araçlar, kısıtlar
Loop	Ajanın ne zaman çalışıp ne zaman duracağını	Zamanlayıcı, kontrol adımı, durma koşulu

Context için Anthropic'in Eylül 2025 yazısı, harness için Mitchell Hashimoto'nun Şubat 2026 yazısı iyi başlangıç noktaları. Hashimoto'nun tarifi akılda kalıcı: ajan bir hata yaptığında, o hatayı bir daha yapmayacağı bir düzen kurmak. Ama tanımlar henüz oturmadı ve kaynaktan kaynağa değişiyor.

Bir döngünün parçaları

Tetikleyici döngüyü başlatır. Ajan işi yapar, sonuç kontrol edilir, durum kaydedilir; iş bitmediyse tur başa döner. Döngü bitince sonuç prod'a doğrudan gitmez, önce insan inceler.

Kaynaklar küçük farklarla aynı parçaları sayıyor:

Tetikleyici: Döngüyü ne başlatıyor? Bir zamanlayıcı, kırılan bir CI işi ya da yeni açılan bir issue olabilir.
Test edilebilir hedef: "Bitti" neye göre bitti? Hedef kötü yazılırsa döngü yanlış şeyi hızla iyileştirir.
Kontrol: Test ve derleyici gibi aynı girdide aynı sonucu veren araçlar önce gelir. Osmani yazan ile kontrol edeni ayırmayı öneriyor, çünkü kendi ödevini notlandıran model fazla iyimser oluyor.
Durma koşulu: Tur sınırı, bütçe ve ilerleme olmadığını fark eden bir kontrol. Bunlar yoksa döngü token yakmaya devam eder.
Hafıza: Model iki çalışma arasında her şeyi unutur. Neyin bittiğini ve sırada ne olduğunu konuşmanın dışında, bir dosyada ya da panoda tutman gerekir.

Ne zaman işe yarar, ne zaman yaramaz?

İyi aday, tekrar eden ve sonucu makineyle kontrol edilebilen iştir. Osmani'nin örneğindeki CI hataları buna uyuyor: sorun bellidir, düzeltme testle sınanır.

Tek seferlik işte durum tersine döner. Machine Learning Mastery, böyle bir işte normal bir ajan oturumunun daha hızlı ve daha güvenli olabileceğini yazıyor. SSD Nodes'un rehberi de ucu açık refactor ve tasarım işlerini henüz uygun görmüyor.

Kontrol adımı da tek başına güvence değil. Machine Learning Mastery'nin verdiği hata örneği, ajanın kırık testi silerek CI'ı yeşile çevirmesi. Ben de AI'ın yazdığı testleri ölçerken kapsam ve mutation skoru %100 çıktığı halde hatanın kaçabildiğini görmüştüm. Yeşil bir sonuç, kontrolün baktığı kadarını söyler.

Faydası da henüz net ölçülmüş değil. Ağustos'ta yayımlanan bir makale 36.710 açık kaynak depoyu tarayıp 217'sinde otonom ajan döngüsü buluyor. Aynı çalışmaya göre konuyu anlatan blog ve rehberler, iddia ettikleri faydalar için sistematik kanıt sunmuyor. Maliyet tarafında da Osmani, alt ajanların daha çok token harcadığını özellikle hatırlatıyor.

Prod kapısı neden insanda kalıyor?

Benim sınırım prod. Hemen her işi yaptırırım ama sonucu incelemeden prod'a göndermem. Neyi incelediğim de projeye göre değişiyor. Backend'de bir iş yaptırıyorsam git diff'ten neler yaptığına bakıyorum ve istediğim mimaride mi diye inceliyorum.

Testler kodun çalışıp çalışmadığını söyler, istediğin mimaride olup olmadığını söylemez. Bu yüzden diff'i okuyan birine hâlâ ihtiyaç var.

Kaynaklar da bu noktada aynı yere çıkıyor. Osmani'ye göre döngünün "bitti" demesi kanıt değil, bir iddia. Üretilen kodu okumazsan sahip olduğun anlayış ile var olan kod arasındaki fark büyüyor; buna anlama borcu (comprehension debt) diyor. Machine Learning Mastery de finansal işlem ve veritabanına yazma gibi hassas adımlardan önce açık insan onayı öneriyor.

İlk döngünü nasıl kurarsın?

Küçük bir işle başla. "Bitti" tanımını çalıştırılabilir bir komut olarak yaz, örneğin bir test komutu. Tur sınırı koy ve döngünün sonucunu prod'a değil, bir PR olarak açtır. Birkaç PR'ı okuduktan sonra hangi kontrollerin eksik kaldığını görürsün.

Scion yazısında review yükünün arttığını yazmıştım. Döngü bir sabahta on PR açtığında bunları kimin okuyacağı ise henüz cevabı net olmayan bir soru.

Bu yazı ilk olarak huseyinbozdemir.com'da yayımlandı.

.NET 11 çıkıyor, .NET 8 ve 9 bitiyor

Hüseyin Bozdemir — Tue, 10 Nov 2026 20:13:38 +0000

10 Kasım 2026 Salı, .NET tarafında üç şey aynı gün oluyor: .NET 8 ve .NET 9'un desteği bitiyor, .NET Conf 2026 açılıyor ve .NET 11 çıkıyor. O gün ayrıca ayın ikinci salısı, yani Microsoft'un aylık yama günü (Patch Tuesday).

Desteğin bitmesi uygulamanın durması demek değil. net8.0 hedefleyen bir servis 11 Kasım sabahı da çalışır. Değişen şey, o günden sonra bulunan bir açık için .NET 8 ve 9'a artık yama çıkmayacak olması. Microsoft'un destek politikasına göre 10 Kasım bu iki sürümün son yama günü.

Neden 8 ve 9 aynı gün bitiyor?

.NET 8 bir LTS (Long Term Support), .NET 9 ise bir STS (Standard Term Support) sürümü. İkisinin farkı yalnızca destek süresinde: sürüm politikası LTS'ye üç, STS'ye iki yıl veriyor.

STS eskiden 18 ay desteklenirdi. Microsoft 16 Eylül 2025'te bu süreyi .NET 9'dan başlayarak 24 aya çıkardı. Gerekçe şuydu: .NET 9'un desteği 12 Mayıs 2026'da, kendisinden bir yıl önce çıkan .NET 8'den altı ay önce bitecekti. Yeni kuralla .NET 8 (Kasım 2023 + üç yıl) ve .NET 9 (Kasım 2024 + iki yıl) aynı güne denk geldi.

LTS üç yıl, STS iki yıl destekleniyor. .NET 8 ve .NET 9 aynı gün, 10 Kasım 2026'da bitiyor. .NET 11 (STS) 9 Kasım 2028'e, .NET 10 (LTS) 14 Kasım 2028'e kadar destekleniyor: aradaki fark beş gün. Kaynak: Microsoft .NET destek politikası.

.NET 11'de neler var?

Microsoft'un .NET 11 yenilikleri listesi uzun. Backend tarafında öne çıkanlar:

Runtime Async: async/await için derleyicinin ürettiği durum makinesi yerine işi runtime'ın kendisi yürütüyor. Sonuç daha temiz stack trace ve daha az yük. net11.0 hedefleyen projelerde artık önizleme bayrağı istemiyor ve .NET'in kendi kütüphaneleri bununla derleniyor.
C# 15: union tipleri ve kapalı sınıf hiyerarşileri (closed hierarchies). Bir metodun "başarılı sonuç ya da şu üç hatadan biri" döndürdüğünü tip sistemiyle anlatmak kolaylaşıyor. Etiketli break/continue ve extension indexer da geliyor.
Decimal32, Decimal64, Decimal128: IEEE 754 standardındaki ondalık kayan nokta tipleri. Mevcut decimal'ın yerini almıyor; başka sistemlerle bu standartta veri alışverişi yapanlar için.
LINQ'te FullJoin: İki listeyi eşleştirip iki taraftan da eşi olmayanları getiren join artık hazır. İki kaynaktaki kayıtları karşılaştıran mutabakat kodu bunun tipik kullanım yeri.
Asenkron doğrulama: DataAnnotations'a AsyncValidationAttribute geldi. Doğrulama sırasında veritabanına ya da bir servise gitmek gerekiyorsa senkron beklemek zorunda değilsin.
HTTP ve sıkıştırma: Zstandard desteği, istek gövdesini sıkıştırma ve havuzdaki HTTP bağlantılarını kendi kuralınla kapatabilme.
İzleme: Activity izlemesini ActivityListener yazmadan, kurallarla açıp kapatabiliyorsun; MemoryCache için hazır OpenTelemetry metrikleri var.
SDK: dotnet nuget add source komutuna --min-publish-age-hours geldi. Yeni yayımlanan bir paketin, belirlediğin süre dolmadan projeye girmesini engelliyor; zehirli sürümlere karşı basit bir tampon.

Yükseltmeden önce: işlemci şartı

.NET 11'in en düşük donanım gereksinimi yükseldi. x64'te taban x86-64-v1'den x86-64-v2'ye çıktı; işlemcinin SSE4.2 ve POPCNT gibi komut setlerini desteklemesi gerekiyor. Intel ve AMD'nin hâlâ desteklediği bütün işlemciler bu şartı karşılıyor.

Takılabileceğin yer eski sunucular ya da işlemci özelliklerini misafir makineye kısıtlı gösteren sanallaştırma ortamları. Şart karşılanmazsa uygulama hiç açılmıyor ve "The current CPU is missing one or more of the baseline instruction sets" benzeri bir hata veriyor.

.NET 11 için neden RC3 çıktı?

.NET'te alışılmış sıra iki sürüm adayı (RC1, RC2), ardından Kasım'da genel sürümdür. Bu yıl 25 Ekim'de bir de RC3 çıktı. Sebep yeni bir özellik değil, takvim dışı bir güvenlik yaması: Brotli sıkıştırma kütüphanesindeki CVE-2026-111497. Aynı gün .NET 8, 9 ve 10'a da yama geldi.

Bu yama, desteği biten sürümde ne kaybettiğini de iyi gösteriyor: aynı açık 11 Kasım'da bulunsaydı .NET 8 ve 9 için düzeltme çıkmayacaktı.

LTS mi, STS mi? Hesap değişti

"Canlıda yalnızca LTS kullanılır" kuralı, STS'nin 18 ay desteklendiği dönemden kalma. Bugün .NET 10 (LTS) 14 Kasım 2028'e, .NET 11 (STS) 9 Kasım 2028'e kadar destekleniyor. 10 Kasım'da .NET 11'e geçen bir ekip, .NET 10'da kalan bir ekipten yalnızca beş gün önce yeniden yükseltme yapmak zorunda kalacak.

Yani seçim artık destek süresine değil, başka sorulara bağlı: .NET 11'in getirdiklerine ihtiyacın var mı, kullandığın kütüphaneler .NET 11'i destekliyor mu, ekibin her yıl sürüm yükseltebiliyor mu?

Kendi sisteminde nasıl kontrol edersin?

Dört yere bakman yeterli: projelerin hedef sürümü, sunucudaki runtime'lar, container imajları ve .NET 11'e geçeceksen işlemci.

# Projelerin hedeflediği sürüm
grep -rE "<TargetFrameworks?>" --include=*.csproj .

# Makinede kurulu runtime'lar
dotnet --list-runtimes

# Dockerfile'lardaki taban imajlar
grep -rn "mcr.microsoft.com/dotnet" --include="Dockerfile*" .

# Linux sunucuda x86-64-v2 için gereken komut setleri (ikisi de görünmeli)
grep -owE "sse4_2|popcnt" /proc/cpuinfo | sort -u

net8.0, net9.0 ya da aspnet:8.0 gibi bir sonuç görürsen o servis 10 Kasım'dan sonra yama almayacak. Self-contained yayımlanan uygulamalar runtime'ı kendi içinde taşıdığı için sunucuyu güncellemek onları kurtarmaz; onları yeniden derleyip yayımlaman gerekir.

Politikaya göre Visual Studio bu sürümleri bir ay sonra "desteği bitmiş" olarak işaretleyecek, altı ay sonra da yeni SDK'lar bu sürümleri hedefleyen projelerde NETSDK1138 uyarısı vermeye başlayacak. Uyarıyı beklemeden listeyi şimdi çıkarmak daha ucuz.

Bu yazı ilk olarak huseyinbozdemir.com'da yayımlandı.

SQL Server'da yavaş sorgu nasıl hızlandırılır?

Hüseyin Bozdemir — Mon, 02 Nov 2026 06:53:51 +0000

POS hareketlerini listeleyen bir endpoint'imiz vardı. Tabloya her gün milyonlarca satır ekleniyordu ve ekranın en sık kullanılan hâli gün bazlı sorguydu: bir işyerinin belli günlerdeki hareketleri, sayfa sayfa. Bu sorgu dakikalar sürüyordu. CreatedDate kolonunda indeks vardı, ama sorgu onu kullanmıyor gibiydi.

Dört değişiklikle sorgu dakikalardan saniyelere indi. Bu yazı için o dört adımı 10 milyon satırlık sentetik bir tabloda yeniden ölçtüm. Ölçümlerden biri, o gün suçladığımız şeyin asıl suçlu olmadığını gösterdi.

Kısa cevap: SQL Server'da yavaş bir listeleme sorgusunu hızlandırırken önce indeksin gerçekten kullanılıp kullanılmadığına bak. Kolona uygulanan fonksiyonlar (CONVERT, DATEDIFF) indeksi devre dışı bırakır; filtrelediğin kolonlar için bileşik indeks gerekir. Derin sayfalarda OFFSET atlanan her satırı okur; cursor (keyset) sayfalama her sayfada aynı maliyettedir. Geniş listelerde önce yalnızca Id'leri seç, kolonları sonra getir. Join'deki bir CTE her satır için yeniden çalışabilir; ara sonucu temp tabloya almak bunu bir kez çalışır hâle getirir.

Ölçüm düzeneği

Gerçek tabloyu ve verisini kullanamam, o yüzden benzerini kurdum. PosHareketleri tablosunda 10 milyon satır var: 30 gün, günde yaklaşık 330 bin hareket. Yanında işyerleri (20 bin), terminaller (60 bin) ve iadeler (200 bin) duruyor. CreatedDate kolonunda tek kolonlu bir indeks var. Bizim tablomuz 30-40 kolondu; buradaki 10 kolon, yani gerçekte farklar daha da büyür.

Ortam SQL Server 2022 Express. Sorgular uygulamanın göndereceği gibi parametreli (sp_executesql), her biri iki kez çalışıyor ve ikincisi sayılıyor; yani önbellek sıcak.

Süreyi raporluyorum ama asıl baktığım sayı mantıksal okuma (logical reads): sorgunun okuduğu 8 KB'lık sayfa sayısı. Süre makineye, önbelleğe ve o anki yüke göre oynar; okuma sayısı oynamaz. İkisini de şöyle açarsın:

SET STATISTICS IO, TIME ON;
-- sorgu
SET STATISTICS IO, TIME OFF;

Messages sekmesinde her tablo için logical reads ve sorgunun CPU ve geçen süresi görünür. Yanına gerçek çalışma planını (actual execution plan, SSMS'te Ctrl+M) açarsan hangi operatörün bu okumaları yaptığını da görürsün.

Tarih filtresi: kolona fonksiyon uygulamak

Gün bazlı sorguda tarih filtresi CreatedDate'i güne çeviriyordu:

WHERE IsyeriId = @isyeri
  AND CAST(CreatedDate AS date) BETWEEN @bas AND @bit

Bir kolona fonksiyon uyguladığında veritabanı genellikle o kolonun indeksinde arama (seek) yapamaz. İndeks CreatedDate'in kendisine göre sıralı; CAST(CreatedDate AS date) ya da CONVERT(char(8), CreatedDate, 112) sonucuna göre değil. Bu durumda her satır için fonksiyonu hesaplayıp sonucu karşılaştırmak zorunda kalır. Bu tür koşullara sargable olmayan (non-sargable) koşul denir.

Biz bunu düzelttik: gelen tarihleri bir gün kaydırıp aralık olarak yazdık.

WHERE IsyeriId = @isyeri
  AND CreatedDate >= @bas
  AND CreatedDate <  DATEADD(day, 1, @bit)

Bu yazı için ölçerken şunu gördüm: SQL Server CAST(... AS date) için bir istisna yapıyor. Kolonu date'e çevirmeyi tanıyor ve indekste yine aralık araması yapabiliyor. Tek günlük, ilk 50 satırlık sorguda dört farklı yazımın sonucu:

Filtre	Okuma	Süre
`CAST(CreatedDate AS date) = @gun`	203	~1 ms
`CreatedDate >= @gun AND CreatedDate < @gun + 1 gün`	215	~0 ms
`DATEDIFF(day, CreatedDate, @gun) = 0`	14.112	1.038 ms
`CONVERT(char(8), CreatedDate, 112) = ...`	169.934	2.066 ms

DATEDIFF indeksi baştan sona tarıyor, CONVERT bütün tabloyu okuyor. CAST ise aralıkla neredeyse aynı. Yani bizim sorgudaki asıl yük CAST değildi.

Aralıkla yazmak yine de doğru alışkanlık. CAST istisnası SQL Server'a özgü ve yalnızca date'e çevirmede geçerli; aynı kod başka bir veritabanında ya da başka bir fonksiyonla aynı şansı bulamaz. Aralık her yerde indeksi kullanır.

Asıl fark işyeri filtresinde çıktı. Aynı sorguyu bir işyeri ve yedi gün için üç farklı indeks durumunda çalıştırdım:

İndeks	Okuma	Süre
Yalnızca `CreatedDate`	169.934	454-611 ms
`CreatedDate` + ayrıca `IsyeriId`	2.044	2 ms
Bileşik `(IsyeriId, CreatedDate)`	215	1-2 ms

Yalnızca tarih indeksi varken yedi günlük aralık 2,3 milyon satıra denk geliyor. Optimizer bu kadar satır için indeksten tek tek tabloya gitmektense bütün tabloyu taramayı seçiyor; CAST'lı ve aralıklı yazımın ikisi de aynı taramaya düşüyor. Bileşik indekste önce işyerine, sonra o işyerinin tarih aralığına iniliyor ve sorgu yalnızca gösterilecek satırları okuyor.

Bileşik indekste kolon sırası önemli: eşitlikle filtrelenen kolon (IsyeriId) önce, aralıkla filtrelenen kolon (CreatedDate) sonra. Ters sırada indeks yine tarih aralığını tarar, işyerini her satırda ayrıca kontrol eder.

Derin sayfada OFFSET neden yavaşlar

Listede sayfalama vardı, ama yetersizdi. Klasik OFFSET ... FETCH sayfalaması şöyle görünür:

SELECT h.Id, h.CreatedDate, h.Tutar, h.KartMaskeli, i.Ad, t.SeriNo
FROM PosHareketleri h
JOIN Isyerleri i ON i.Id = h.IsyeriId
JOIN Terminaller t ON t.Id = h.TerminalId
WHERE h.CreatedDate >= @bas AND h.CreatedDate < @bit
ORDER BY h.CreatedDate DESC, h.Id DESC
OFFSET @atla ROWS FETCH NEXT 50 ROWS ONLY;

OFFSET 50000 "50 bininci satırdan başla" demek değil, "50 bin satırı oku, at, sonra 50 satır ver" demek. Veritabanının atlanacak satırların yerini bilmesinin başka yolu yok. Sayfa ilerledikçe okunan ve atılan satır sayısı artar.

Bir günün hareketlerinde (yaklaşık 330 bin satır) 50'lik sayfalarla ölçünce:

Sayfa	Okuma	Süre
1	215	2 ms
100	20.339	21 ms
1.000	203.269	176 ms
6.000	169.934 (tablo taraması)	918 ms

1.000. sayfada işyeri ve terminal tablolarından da 103'er bin okuma var: sorgu atlanacak satırlar için de join yapıyor. 6.000. sayfada optimizer indeksi bırakıp tabloyu taramaya geçiyor. Bizim tablomuz 30-40 kolon olduğu için atılan her satır daha pahalıydı.

Geçici çözümümüz cursor sayfalama oldu. Fikir, "kaçıncı sayfadayım" yerine "en son hangi satırda kaldım" bilgisini taşımak. İstemci bir sonraki sayfayı isterken önceki sayfanın son satırının CreatedDate'ini ve Id'sini gönderir; sorgu oradan devam eder:

SELECT TOP (50) h.Id, h.CreatedDate, h.Tutar, h.KartMaskeli, i.Ad, t.SeriNo
FROM PosHareketleri h
JOIN Isyerleri i ON i.Id = h.IsyeriId
JOIN Terminaller t ON t.Id = h.TerminalId
WHERE h.CreatedDate >= @bas AND h.CreatedDate < @bit
  AND (h.CreatedDate < @sonTarih
       OR (h.CreatedDate = @sonTarih AND h.Id < @sonId))
ORDER BY h.CreatedDate DESC, h.Id DESC;

Bu sorgu indekste doğrudan kaldığı yere iner ve 50 satır okur. Ölçümde her sayfa 220 civarı okuma ve 2-3 ms; 1. sayfayla 6.000. sayfa arasında fark yok.

Bedeli de var: kullanıcı "47. sayfaya git" diyemez, yalnızca ileri ve geri gidebilir. Listede toplam sayfa sayısı gösteriliyorsa onu ayrı bir COUNT ile hesaplamak gerekir. Hareket listesi gibi kullanıcının genellikle baştan aşağı kaydırdığı ekranlarda bu kayıp küçük.

GUID'li tenant'larda cursor

Bizde bazı tenant'ların Id'leri long, bazılarınınki GUID'di. GUID'li tenant'larda Id üzerinden büyüktür/küçüktür yapamıyorduk, o yüzden cursor'dan yalnızca long Id'li tenant'lar yararlanabildi. Aslında sıralama zaten CreatedDate'e göre; Id yalnızca aynı tarihli satırları ayırmaya yarıyor. Bu iş için Id'nin sıralı olması değil, tekil olması ve her seferinde aynı sırayı vermesi yeterli. SQL Server'da GUID'ler de kendi (tuhaf ama tutarlı) sıralarıyla karşılaştırılabildiği için yukarıdaki sorgu GUID'le de çalışır. Tek dikkat: son Id'yi uygulamada karşılaştırma, olduğu gibi SQL'e geri gönder; .NET'teki Guid sıralaması SQL Server'ınkiyle aynı değil.

Önce Id'leri seç, kolonları sonra getir

Cursor'ın kullanılamadığı tenant'lar için başka bir yol bulduk: önce olabildiğince filtreleyip yalnızca Id'leri seçmek, join'leri ve kolonları ikinci adımda yapmak.

WITH sayfa AS (
    SELECT Id, CreatedDate
    FROM PosHareketleri
    WHERE CreatedDate >= @bas AND CreatedDate < @bit
    ORDER BY CreatedDate DESC, Id DESC
    OFFSET @atla ROWS FETCH NEXT 50 ROWS ONLY
)
SELECT h.Id, h.CreatedDate, h.Tutar, h.KartMaskeli, i.Ad, t.SeriNo
FROM sayfa s
JOIN PosHareketleri h ON h.Id = s.Id
JOIN Isyerleri i ON i.Id = h.IsyeriId
JOIN Terminaller t ON t.Id = h.TerminalId
ORDER BY s.CreatedDate DESC, s.Id DESC;

İç sorgu yine OFFSET kullanıyor ve yine atlanan satırları okuyor, ama bunu yalnızca CreatedDate indeksinde yapıyor. İndeks dar: içinde tarih ve Id var, 30-40 kolon yok. Join'ler ve geniş satırlar yalnızca seçilen 50 Id için yapılıyor. Bu kalıba deferred join de deniyor.

Grafik: bir günlük hareketlerde (yaklaşık 330 bin satır, 50 satırlık sayfa) sayfa numarasına göre süre. OFFSET: 1. sayfa 2 ms, 100. sayfa 21 ms, 1.000. sayfa 176 ms, 6.000. sayfa 918 ms. Önce Id, sonra join: 6.000. sayfa 28 ms. Cursor: her sayfa 2-3 ms.

6.000. sayfada OFFSET 918 ms'ten bu yazımla 28 ms'e iniyor, okuma 170 binden 998'e düşüyor. Cursor kadar düz değil ama sayfa numarasına göre gitme imkânını koruyor.

Join'deki CTE her satırda çalışınca

Filtrelenmiş Id'leri önce bir CTE'de toplayıp ana sorguya join'liyorduk. Planı incelediğimizde CTE'nin her satır için yeniden çalıştığını gördük ve temp tabloya geçmek zorunda kaldık.

Sebebi, SQL Server'ın CTE'yi bir ara tablo gibi saklamaması. CTE, sorguya gömülen bir alt sorgudur (inline). Optimizer onu nested loops join'in iç tarafına koyarsa, dış taraftan gelen her satır için o alt sorgu yeniden çalışır. Sentetik tabloda aynı şekli kurdum: bir işyeri aralığı ve bir haftalık hareketlerin Id'leri CTE'de, dışarıda join'ler ve iade toplamı.

WITH secilen AS (
    SELECT h.Id FROM PosHareketleri h
    WHERE h.IsyeriId BETWEEN @isyeriBas AND @isyeriBit
      AND h.CreatedDate >= @bas AND h.CreatedDate < @bit
)
SELECT h.Id, h.CreatedDate, h.Tutar, h.KartMaskeli, i.Ad, t.SeriNo,
       (SELECT SUM(r.IadeTutar) FROM Iadeler r WHERE r.HareketId = h.Id) AS IadeToplam
FROM PosHareketleri h
JOIN Isyerleri i ON i.Id = h.IsyeriId
JOIN Terminaller t ON t.Id = h.TerminalId
WHERE h.Id IN (SELECT Id FROM secilen)
ORDER BY h.CreatedDate DESC
OFFSET 0 ROWS FETCH NEXT 50 ROWS ONLY;

Gerçek planda optimizer dış tarafta tarih indeksini sondan başa tarıyor ve CTE'nin PosHareketleri aramasını her satır için bir kez çalıştırıyor. Plandaki "Number of Executions" değeri 5.002.003. Sonuç 40,6 milyon okuma ve 9 saniye.

Temp tabloyla aynı iş iki adım:

SELECT h.Id, h.CreatedDate
INTO #secilen
FROM PosHareketleri h
WHERE h.IsyeriId BETWEEN @isyeriBas AND @isyeriBit
  AND h.CreatedDate >= @bas AND h.CreatedDate < @bit;

SELECT h.Id, h.CreatedDate, h.Tutar, h.KartMaskeli, i.Ad, t.SeriNo,
       (SELECT SUM(r.IadeTutar) FROM Iadeler r WHERE r.HareketId = h.Id) AS IadeToplam
FROM #secilen s
JOIN PosHareketleri h ON h.Id = s.Id
JOIN Isyerleri i ON i.Id = h.IsyeriId
JOIN Terminaller t ON t.Id = h.TerminalId
ORDER BY h.CreatedDate DESC
OFFSET 0 ROWS FETCH NEXT 50 ROWS ONLY;

Filtre bir kez çalışıyor, sonuç #secilen'e yazılıyor. SQL Server temp tabloya istatistik de oluşturduğu için ikinci sorguda kaç satırla çalışacağını biliyor. İki adım toplam 0,85 saniye; CTE'li hâlin onda biri. Bizde de temp tablo sorguya özeldi; sorgu bitince düşüyordu, ayrıca indeks koymadık.

Temp tablonun bedeli, sorgunun artık tek bir ifade olmaması. ORM'in ürettiği tek bir SELECT ile yapılamıyor; ya ham SQL ya da stored procedure gerekiyor. Ara sonuç çok büyükse tempdb'ye yazmanın maliyeti de hesaba girer.

Kendi sisteminde nasıl fark edersin

Yavaş bir sorguyu SET STATISTICS IO ON ile çalıştır ve okuma sayısını, sorgunun döndürdüğü satır sayısıyla karşılaştır. 50 satır gösteren bir liste için yüz binlerce okuma görüyorsan sorgu ihtiyacından fazlasını okuyor.

Sonra gerçek çalışma planında iki şeye bak: indeks üzerinde Seek yerine Scan olan operatörler ve "Number of Executions" değeri 1'den çok büyük olan operatörler. İlki indeksin kullanılmadığını, ikincisi bir alt sorgunun ya da CTE'nin her satırda yeniden çalıştığını gösterir. EF Core kullanıyorsan önce üretilen SQL'i log'dan al; Include ve Select yazısında ORM tarafındaki karşılığını anlatmıştım.

Bizim sorguyu dakikalardan saniyelere indiren tek bir değişiklik olmadı. Ölçümde dört adımın ortak noktası aynı çıktı: ekranda gösterilmeyecek satırı okumamak.

Bu yazı ilk olarak huseyinbozdemir.com'da yayımlandı.

İnternet yokken kartla ödeme nasıl onaylanır?

Hüseyin Bozdemir — Sat, 31 Oct 2026 13:05:09 +0000

İnternet ya da elektrik gidince marketteki POS bankaya ulaşamaz. Bugün çoğu yerde kartla ödeme orada biter ve kasiyer nakit olup olmadığını sorar. Mastercard bunu Avrupa'da değiştiriyor: 8 Ekim'de duyurduğu kurala göre Şubat 2027'den sonra basılan her Mastercard kartı, Mayıs 2027'den sonra takılan her yeni POS da bağlantı yokken ödeme alabilecek (The Paypers).

Çevrimdışı ödeme (offline payment), POS'un o an bankaya soramadığı kart ödemesi. Bu adla iki ayrı şey anılıyor: kartın çipinin ödemeyi kendisi onaylaması ve POS'un işlemi saklayıp bağlantı gelince bankaya sorması. Mastercard'ın kuralı birincisi. Aradaki fark, para yetmediğinde açığın kimde kalacağını belirliyor.

Diyagram: Kesintiden kurala zaman çizelgesi. Nisan 2025'te İspanya ve Portekiz'de elektrik kesintisi. Ekim 2026'da Mastercard çevrimdışı ödeme kuralını duyurdu. Şubat 2027'den itibaren yeni basılan kartlar, Mayıs 2027'den itibaren yeni takılan POS'lar çevrimdışı ödemeyi destekleyecek.

28 Nisan 2025'te İspanya ve Portekiz'de elektrik kesildi. Mastercard kuralı 8 Ekim 2026'da duyurdu. Şubat 2027'den sonra basılan kartlar, Mayıs 2027'den sonra takılan ya da değiştirilen POS'lar bağlantısız ödeme alabilecek.

Kural nereden çıktı?

28 Nisan 2025'te İspanya ve Portekiz'de elektrik kesildi. Mastercard'a göre o gün yaklaşık 55 milyon kişi dijital ödeme yapamadı. Danimarka, İsveç, Estonya ve Letonya'da çevrimdışı ödeme zaten kullanılıyor; Letonya'daki bir fırtınada jeneratörle çalışan dükkânlarda kartla ödeme sürmüş (Electronic Payments International).

Yeni kural bunu Avrupa'nın geneline yayıyor. POS tarafı bir gecede değişmeyecek; dükkânlar cihazlarını yeniledikçe yayılacak.

Kart kendisi onaylayınca

Kartın çipi küçük bir bilgisayar. Ödeme sırasında POS çipe tutarı ve kendi kontrollerinin sonucunu verir, çip de üç cevaptan birini döner: onay (TC), "bankaya sor" (ARQC) ya da ret (AAC). Normal bir günde çip neredeyse her zaman "bankaya sor" der ve kararı banka verir.

Bağlantı yokken bu yol kapalı. Burada devreye giren, çipli kartların ödeme standardı EMV'nin bağlantısız onayı; sektörde adı offline EMV. Karar, bankanın kartı basarken çipe yazdığı kurallara kalıyor: PIN doğru mu, tutar çevrimdışı limitin içinde mi, kart art arda kaç kez bankaya sorulmadan kullanılmış. Hepsi tamamsa çip işlemi imzalayıp onaylıyor. Bu imza, bankanın işlemi sonradan gördüğünde gerçekten o karttan geldiğini doğrulamasını sağlıyor.

Diyagram: Bağlantı yokken onayı çip verir. POS bankaya ulaşamıyor ve tutarı çipe soruyor. Çip, bankanın önceden yazdığı kurallara bakıyor: PIN doğru mu, tutar çevrimdışı limitin içinde mi, art arda kaçıncı bağlantısız işlem. Üç cevaptan birini veriyor: onay (TC, çip işlemi imzalar), bankaya sor (ARQC, bağlantı olmadığı için yapılamaz) ya da ret (AAC).

Normal günde çip neredeyse her zaman "bankaya sor" der. Bağlantı yokken bu yol kapalı; karar, bankanın kartı basarken çipe yazdığı kurallara kalır.

Mastercard'ın kuralında harcama limiti çipte duruyor ve onu kartın bankası belirliyor. Tek işlemde üst sınır 200 euro. Limit çipte olduğu için kart hangi POS'a takılırsa takılsın harcama aynı sayaçtan düşüyor; iki ayrı markette art arda alışveriş yapıp limiti ikiye katlamak mümkün değil.

Çipin bilmediği tek şey hesaptaki para.

Bakiye yetmezse işlem yine onaylanmış olur ve bağlantı gelince takasa gider. Açık bankada kalır. Limiti bankanın koyması da bu yüzden: ne kadar risk alacağına kendisi karar veriyor.

POS saklayıp sonra sorunca

İkinci yolun adı store and forward (sakla ve ilet). Burada çip yine "bankaya sor" der. POS soramayınca işlemi saklar, ekranda kabul gösterir ve bağlantı gelince normal onay isteğini gönderir. Yani o anda kimse onay vermemiştir, karar yalnızca ertelenmiştir (offline EMV ile farkı).

Banka saatler sonra işlemi yetersiz bakiye ya da kapalı hesap yüzünden reddedebilir. Satıcı ürünü çoktan vermiştir. Adyen'in dokümanı bunu açıkça yazıyor: çevrimdışı alınan ödemelerde başarısız tahsilat ve itiraz riski satıcıda (Adyen). Sağlayıcıların bu yolda tutar, adet ve süre sınırı koyması bundan.

Backend'den bakınca bu, idempotency yazısındaki "bankaya iletildi" durumuna benziyor: ödeme alınmış görünüyor ama sonucunu henüz kimse bilmiyor. Farkı, burada ürünün çoktan kapıdan çıkmış olması.

Risk kimde kalıyor?

Diyagram: Çevrimdışı ödemenin iki yolu. Çip onaylar (offline EMV): kararı çip bankanın kurallarıyla verir, banka sonradan reddedemez, para yetmezse açık bankada ve limitle sınırlı kalır. POS saklar (store and forward): o anda kimse onay vermez, POS kabul gösterir; banka saatler sonra reddedebilir ve açık satıcıda kalır.

İkisi de kasada "onaylandı" gösterebilir. Farkı, para yetmediğinde ortaya çıkar.

Çevrimdışı EMV'de risk bankanın çizdiği limitle sınırlı. Çip PIN'i kendisi doğruladığı için PIN'i bilinmeyen çalıntı bir kart da işe yaramıyor. Store and forward'da sınırı ödeme sağlayıcısı koyuyor ama bedeli satıcı ödüyor. Kasadaki ekran iki durumda da "onaylandı" diyebilir.

Türkiye'nin bu kurala dahil olup olmadığını duyurulardan çıkaramadım. Haberler "Avrupa" diyor ve ülke listesi vermiyor.

Bu yazı ilk olarak huseyinbozdemir.com'da yayımlandı.

Ajanlı ödeme nedir? Yapay zekâ nasıl öder?

Hüseyin Bozdemir — Sat, 31 Oct 2026 13:04:46 +0000

20 Ekim'de iki kart ağı aynı gün, yapay zekâ ajanlarının ödeme yapmasını gerçek işlemlerle denemeye başladı. Visa, fatura ödeme platformu BILL ve tedarikçi portalı Billtrust'la canlı bir pilot duyurdu. Mastercard da aynı gün geliştiricilere "Agent Pay for Machines" için erken erişim açtı (The Block).

Ajanlı ödeme (agentic payments), insanın sınırını önceden çizdiği bir yetkiyle bir yazılımın, yani bir yapay zekâ ajanının ödemeyi kendisi yapması. Haberi ilk okuduğumda iki şeyi anlamadım: ödemeyi yapay zekâ mı yapacak, kart numarası olmadan nasıl ödeyecek? İkisinin cevabı da haberin içinde.

Ödemeyi yapay zekâ mı yapacak?

Kararı hâlâ insan veriyor. Visa pilotunda BILL'in ödeme ajanı yalnızca alıcının daha önce onayladığı faturaları ödüyor; Visa'ya göre ajan ödeme kararı vermiyor, onaylanmış talimatı yerine getiriyor. Eskiden biri her tedarikçinin portalına tek tek girip öderdi, şimdi bu tekrarı ajan yapıyor. Pilot canlıda ve gerçek işlemler işleniyor.

Mastercard'ın tarafı makineden makineye ödeme. Bir yazılım iş yaparken kullanım başına ücretli bir servise ihtiyaç duyuyor; insan bir bütçe veriyor, ajan o bütçe içinde kendisi ödüyor. Sistem, ödemeyi HTTP'nin içine gömen açık protokol x402 üzerine kurulu: servis 402 Payment Required dönüyor, ajan imzalı bir ödeme kuponu gönderiyor, satıcı kuponu doğrulayıp hizmeti veriyor ve kuponlar sonra toplu tahsil ediliyor. 402 kodu HTTP standardında hâlâ "ileride kullanılmak üzere" ayrılmış duruyor. Demoda bir ajan, onaylı tek bir bütçeden iki sağlayıcıya dokuz ödeme yaptı. Mastercard'ın teknik dokümanı henüz herkese açık değil; ayrıntılar şimdilik basın haberlerinden.

"Bana 3.000 liranın altında bir uçak bileti bul ve al" diyen bireysel kullanıcı ise bu pilotların kapsamında değil.

Kart numarası olmadan nasıl ödüyor?

İki ayrı parça birlikte çalışıyor: parayı token taşıyor, kimliği imza kanıtlıyor.

Token. Visa pilotunda ajan, tokenize edilmiş ödeme bilgisiyle ödüyor. Apple Pay ya da Google Pay'de olan da bu: telefon satıcıya karta bağlı ayrı bir numara gönderir, kart ağı onu arkada gerçek kartla eşleştirir ve para yine kart hesabından çıkar. Visa ajan token'ının biçimini ve hangi sınırları taşıyabildiğini açıklamadı.

İmza. Satıcı, karşısındakinin kayıtlı bir ajan mı yoksa sıradan bir bot mu olduğunu Visa'nın Trusted Agent Protocol şartnamesiyle anlıyor. Ajan her HTTP isteğini RFC 9421 HTTP Message Signatures ile imzalıyor; satıcı ajanın açık anahtarını Visa'nın /keys uç noktasından JWK olarak çekip imzayı doğruluyor. Şartnamedeki kurallar kısa:

İmzada en az @authority, @path, created, expires, keyid, alg, nonce ve tag bulunmalı; biri eksikse istek engellenir.
created ile expires arası 8 dakikayı geçemez.
Satıcı son 8 dakikada gördüğü nonce'ları tutar, aynısı tekrar gelirse isteği engeller. Bu, idempotency ile aynı aileden bir kontrol: aynı isteğin ikinci kez işlenmemesi.
tag gezinmede agent-browser-auth, ödemede agent-payer-auth değerini taşır.

Visa'ya göre bu doğrulama, sitelerin bugüne kadar CAPTCHA ve bot engelleme ile sağladığı korumanın yerini tutabiliyor. Ajan ayrı bir portal girişine de ihtiyaç duymuyor.

Diyagram: Ajanlı ödemenin iki yolu: Visa ve Mastercard. Solda Visa: insan faturayı onaylar, ajan isteği RFC 9421 ile imzalar (8 dakika geçerli, tek kullanımlık nonce), satıcı ajanın açık anahtarını Visa dizininden alıp imzayı doğrular, ödeme gerçek kart numarası yerine token ile yapılır. Sağda Mastercard: insan bütçe verir, ücretli servis HTTP 402 Payment Required döner, ajan bütçe içinde imzalı bir ödeme kuponu gönderir, kuponlar sonra toplu tahsil edilir.

İki ağ aynı soruya farklı cevap veriyor. Visa kart altyapısının üstüne bir kimlik katmanı ekliyor; Mastercard ödemeyi doğrudan HTTP'nin içine gömüyor. İkisinde de karar insanda, sınır önceden çiziliyor.

Benim yorumum

Fikir bana mantıklı geliyor ama temkinliyim. Bu haberdeki parçaların hiçbiri ödeme dünyası için yeni değil; yeni olan, bankalarla tek tek kurduğumuz şeylerin ilk kez herkes için standart hâle gelmesi.

Token'ı düşünelim. Daha önce çalıştığım bir kart saklama modülünde kartı şifreleyip saklıyor, işlemi o kartın token'ıyla yapıyorduk. Ama o token yalnızca bizim sistemimizin içinde anlam taşıyordu. Bankaya giderken şifre çözülüyor, kart numarası yine yola çıkıyordu. Ağ düzeyindeki token'da gerçek numara hiç dolaşmıyor. Kart numarasının nerelere sızabildiğini gören biri için bu küçük bir fark değil.

İmza tarafı bana çok tanıdık geldi. Bir bankayla entegrasyonda body açık gidiyor, header'da body'nin private key ile imzalanmış hâli taşınıyordu. İmzanın içinde zaman damgası ve requestId gibi tek kullanımlık bir değer de vardı. Visa'nın 8 dakika ve nonce kuralı bunun standart hâli. Bugün her banka kendi header adını, kendi kuralını istiyor ve anahtarlar PEM dosyası olarak elle değiş tokuş ediliyor. Burada anahtar bir dizinden geliyor ve kural herkes için aynı.

Limit kısmında daha az eminim. Günlük tutar limiti gibi kurallar "ne kadar" sorusunu çözüyor, "doğru şeyi mi aldı" sorusunu çözmüyor. Onaylı bir fatura gibi önceden bilinen ödemede bu yeter. Ajanın kendi seçtiği bir alışverişte yetmez.

Türkiye'de de benzer bir ayrım görüyorum. Benim gördüğüm kadarıyla saklı kartla tekrarlı ödemede ilk işlem 3DS ile onaylanıyor, sonrakiler 3DS sormadan geçebiliyor. Önceden onaylı ajan ödemesi bu kalıba oturur; ajanın kendi seçtiği alışveriş ise yine 3DS ister.

Asıl açık soru sorumluluk. Ajan limit içinde ama yanlış bir ödeme yaparsa parayı kim geri öder: kart sahibi mi, ajanı yapan şirket mi, satıcı mı? Bunu henüz kimse bilmiyor. Pilotların zaten onaylanmış faturalarla başlamasının sebebi de bence bu.

Bugün yapabileceğin tek şey varsa, kendi imzalama yapına bakmak: istekler zaman damgası ve tek kullanımlık bir değer taşıyor mu, aynı istek ikinci kez gelince reddediliyor mu? Ajanlar Türkiye'ye geldiğinde ilk sorulacak soru büyük ihtimalle bu olacak.

Bu yazı ilk olarak huseyinbozdemir.com'da yayımlandı.

EF Core performansı: Include mı, Select mi?

Hüseyin Bozdemir — Sat, 24 Oct 2026 12:19:54 +0000

Son işlemler raporu açılmıyordu. Ekran ya timeout'a düşüyor ya da o kadar geç geliyordu ki kullanıcı çoktan sayfayı yenilemiş oluyordu. Tablo çok genişti, rapor da tek bir işlemi göstermek için işyerine, karta, bankaya, iadelere ve durum geçmişine uzanıyordu. Kodda bunların hepsi birer Include olarak duruyordu.

EF Core'un log'unu açınca sebebi gördük: gereksiz bir sürü select, gereksiz subquery'ler. Rapor ekranda birkaç kolon gösteriyordu, sorgu ise o işlemle ilişkili her tablonun bütün kolonlarını getiriyordu.

Kısa cevap: raporda Include kullanma, Select ile projeksiyon yap. Include ilişkili entity'leri bütün kolonlarıyla yükler; koleksiyon Include'ları ana satırı çoğaltır. Select ise yalnızca raporun gösterdiği alanları ister, toplamları da SQL'de hesaplatır. Bizde rapor bu değişiklikle baya hızlandı.

Bu yazıda o raporun nasıl düzeldiğini, projeksiyona geçerken çıkan tuzağı, EF Core'un kendi çözümü olan AsSplitQuery'yi ve hâlâ çözmediğimiz kısmı anlatacağım. Örnekler sadeleştirilmiş, alan adları jenerik; mantık aynı.

Include sana ne getiriyor?

Include, bir entity'yi yüklerken ilişkili entity'leri de aynı sorguda yüklemeyi söyler (eager loading). Entity'nin tamamını, tablonun bütün kolonlarıyla yükler. Bir ödemeyi işyeriyle birlikte istediğinde işyeri tablosunun adresi, vergi bilgisi, ayarları da gelir.

Raporu ilk yazdığımızda sorgu kabaca şöyleydi:

var payments = await db.Payments
    .Include(p => p.Merchant)
    .Include(p => p.Card).ThenInclude(c => c.Bank)
    .Include(p => p.Refunds)
    .Include(p => p.StatusHistory).ThenInclude(h => h.ChangedBy)
    .Where(p => p.PaymentDate >= from && p.PaymentDate < to)
    .OrderByDescending(p => p.PaymentDate)
    .Skip(page * PageSize).Take(PageSize)
    .ToListAsync(ct);

var rows = payments.Select(p => new PaymentRow(
    p.Id,
    p.PaymentDate.ToString("dd.MM.yyyy HH:mm"),
    MoneyFormat.Format(p.Amount, p.Currency),
    p.Merchant.Name,
    p.Card.MaskedPan,
    p.Card.Bank.Name,
    p.Refunds.Sum(r => r.Amount),
    p.StatusHistory.Max(h => h.ChangedAt)));

Okurken masum görünüyor. Sayfalama var, filtre var, 20 satır geliyor. Sorun SQL tarafında.

Tekil ilişkiler (Merchant, Card, Bank) birer JOIN olur ve her biri kendi tablosunun bütün kolonlarını sonuca ekler. Koleksiyonlar (Refunds, StatusHistory) daha pahalıdır: EF Core varsayılan olarak her şeyi tek sorguda getirdiği için iki koleksiyon da ödeme satırına JOIN'lenir ve satırlar çarpılır. İki iadesi ve üç durum kaydı olan bir ödeme veritabanından altı satır olarak döner; ödemenin, işyerinin, kartın ve bankanın bütün kolonları bu altı satırın her birinde tekrar eder. Buna cartesian explosion deniyor.

Örnek bir ödeme: iki iadesi ve üç durum kaydı var. Include'lu sorgu bu ödeme için altı satır ve on dört kolon döndürür; ödemenin, işyerinin, kartın ve bankanın kolonları her satırda tekrar eder, satırlar iki iade ile üç durum kaydının çarpımından gelir. Select projeksiyonu aynı ödeme için tek satır ve yalnızca raporun gösterdiği kolonları döndürür; iade toplamı ve son durum tarihi SQL'de hesaplanır.

Bir de sayfalama var. Satırlar çarpılınca Skip/Take'i doğrudan sonuca uygulamak yanlış olurdu (20 ödeme yerine 20 JOIN satırı alırdın). EF Core bunu doğru yapar: önce 20 ödemeyi bir alt sorguda seçer, sonra ilişkileri o alt sorguya bağlar. Sonuç doğru, ama log'da gördüğümüz subquery'ler buradan geliyordu. Sadeleştirilmiş hali kabaca şöyle:

SELECT p.*, m.*, c.*, b.*, r.*, h.*, u.*      -- her tablonun bütün kolonları
FROM (
    SELECT * FROM Payments
    WHERE PaymentDate >= @from AND PaymentDate < @to
    ORDER BY PaymentDate DESC
    OFFSET @skip ROWS FETCH NEXT @take ROWS ONLY
) AS p
JOIN Merchants m ON ...
JOIN Cards c ON ...
JOIN Banks b ON ...
LEFT JOIN Refunds r ON ...
LEFT JOIN (SELECT ... FROM StatusHistory h JOIN Users u ON ...) AS h ON ...
ORDER BY p.PaymentDate DESC, p.Id, m.Id, c.Id, b.Id, r.Id, h.Id

Ekranın gösterdiği sekiz alan için bu kadar veri geliyordu. Sorguda AsNoTracking() yoksa C# tarafı bir de her entity'yi change tracker'a kaydeder; raporda hiçbir şeyi değiştirmediğin halde.

Üretilen SQL'i görmek

Biz sorunu EF Core'un log'unda gördük. İki yolu var. Geliştirme ortamında context'e log bağlarsın:

builder.Services.AddDbContext<AppDbContext>(o => o
    .UseSqlServer(connectionString)
    .LogTo(Console.WriteLine, LogLevel.Information));

Ya da tek bir sorgunun SQL'ini çalıştırmadan alırsın: ToListAsync'ten önceki IQueryable üzerinde ToQueryString() çağırırsın. Rapor sorgusunu yazarken bir kez bakmak çoğu zaman yeter.

Log'da parametre değerlerini de görmek için EnableSensitiveDataLogging() diye bir seçenek var. Ödeme sisteminde bunu yalnızca yerelde aç; parametrelerin içinde kart ya da müşteri bilgisi olabilir ve log'a düşen veriyi geri toplamak zor. Bunu log maskeleme yazısında ayrıca anlattım.

Rapor ne istiyorsa onu iste: Select ile projeksiyon

Çözümün ilk ve en büyük adımı Include'ları atıp sorguyu doğrudan raporun ihtiyacına göre yazmak oldu:

var data = await db.Payments
    .Where(p => p.PaymentDate >= from && p.PaymentDate < to)
    .OrderByDescending(p => p.PaymentDate)
    .ThenByDescending(p => p.Id)
    .Select(p => new PaymentRowData(
        p.Id,
        p.PaymentDate,
        p.Amount,
        p.Currency,
        p.Merchant.Name,
        p.Card.MaskedPan,
        p.Card.Bank.Name,
        p.Refunds.Sum(r => (decimal?)r.Amount) ?? 0m,
        p.StatusHistory.Max(h => (DateTime?)h.ChangedAt)))
    .Skip(page * PageSize).Take(PageSize)
    .ToListAsync(ct);

Burada birkaç şey birden değişiyor:

Navigation'lar hâlâ kullanılabiliyor. p.Merchant.Name yazdığında EF Core JOIN'i kendisi kurar, ama yalnızca Name kolonunu seçer. Include yazmana gerek yok. Sorgu artık entity değil DTO döndürdüğü için yazsan da EF Core Include'u yok sayar.
Koleksiyonlar satır çoğaltmıyor. İade toplamı ve son durum tarihi SQL'de alt sorgu olarak hesaplanıyor; her ödeme tek satır dönüyor. (decimal?) ve ?? 0m iadesi olmayan ödemede SUM'ın NULL dönmesine karşı.
Change tracking yok. Projeksiyon entity döndürmediği için EF Core sonucu takip etmez. Raporda AsNoTracking() yazmayı unutup unutmadığını düşünmene gerek kalmaz.
Sıralama tekil. ThenByDescending(p => p.Id) aynı saniyede düşmüş ödemeler arasında sırayı sabitliyor. Neden önemli olduğu aşağıda, AsSplitQuery bölümünde.

Bu değişiklik raporu baya hızlandırdı; SP'ye ya da ham SQL'e geçmeye gerek kalmadı. Mimaride EF Core kullanıyoruz; projeksiyonla yetinebildiğimiz sürece orada kalıyoruz.

Select içindeki metot neden patlıyor?

Projeksiyona geçerken ilk denemede formatlama gibi metotlar da Select'in içindeydi:

.Select(p => new PaymentRow(
    p.Id,
    p.PaymentDate.ToString("dd.MM.yyyy HH:mm"),
    MoneyFormat.Format(p.Amount, p.Currency),   // C# metodu
    p.Merchant.Name,
    // ...
))
.Skip(page * PageSize).Take(PageSize)
.ToListAsync(ct);   // InvalidOperationException: ... could not be translated.

Hata "could not be translated" oldu. EF Core, SQL'e çeviremediği bir C# metodunu yalnızca en dıştaki Select'te kabul eder: o durumda gereken kolonları SQL'den alır, metodu bellekte çalıştırır. Client evaluation dokümanı bunu "top-level projection" diye anlatıyor. Bizim sorguda Select'ten sonra Skip/Take geliyordu; Select artık en dışta değildi ve EF Core sorgunun tamamını SQL'e çevirmek zorundaydı. MoneyFormat.Format'ın SQL karşılığı yok.

Çözüm sırayı ayırmak oldu. SQL'den ham değerleri sayfalanmış olarak al, formatlamayı sonra bellekte yap:

// data: yukarıdaki projeksiyon sorgusundan gelen 20 satır
return data.Select(d => new PaymentRow(
    d.Id,
    d.PaymentDate.ToString("dd.MM.yyyy HH:mm"),
    MoneyFormat.Format(d.Amount, d.Currency),
    d.MerchantName,
    d.MaskedPan,
    d.BankName,
    MoneyFormat.Format(d.RefundTotal, d.Currency),
    d.LastStatusAt)).ToList();

Formatlama artık yalnızca sayfadaki 20 kayıt üzerinde çalışıyor; maliyeti ölçülemeyecek kadar küçük. Bu ayrımın bir faydası daha var: tarih ve para biçimi kültüre bağlı bir sunum işi. SQL'e taşınsaydı bile orada durmaması gerekirdi.

AsSplitQuery: EF Core'un kendi çözümü

"Include yavaş" diye aradığında karşına çıkan ilk öneri büyük ihtimalle AsSplitQuery() olur. EF Core 5'ten beri var ve koleksiyon Include'larında satır çarpılmasını çözüyor: tek sorgu yerine her koleksiyon için ayrı bir SQL sorgusu çalıştırır. Ödemeler bir sorguda, iadeler ikinci sorguda, durum geçmişi üçüncü sorguda gelir; satırlar çarpılmaz.

Ama yalnızca satır çarpılmasını çözer. Her entity yine bütün kolonlarıyla gelir, change tracking yine çalışır, veritabanına bir yerine üç kez gidilir. Sorgular arasında veri değişirse (transaction içinde değilsen) ödeme bir anın, iadeleri bir sonraki anın verisi olabilir.

Raporu düzelttiğimizde AsSplitQuery'yi bilmiyordum. Bilseydim de projeksiyonu seçerdim; projeksiyon bence daha esnek. Raporun hangi alanı istediğine sen karar veriyorsun, toplamı SQL'de mi bellekte mi yapacağını sen seçiyorsun. AsSplitQuery ise entity'yi tam yüklemenin gerçekten gerektiği yerde, örneğin bir ödemeyi ilişkileriyle düzenlemek için açtığın ekranda anlamlı.

Sayfalamada sıralama tekil olmalı

AsSplitQuery'yi Skip/Take ile kullanıyorsan bilmen gereken bir tuzak var. Bölünmüş sorguların her biri "hangi 20 ödeme?" sorusunu veritabanına yeniden sorar: iadeleri getiren sorgu, ödemeleri seçen filtreyi, sıralamayı ve OFFSET'i bir alt sorgu olarak tekrarlar. Cevabın her seferinde aynı çıkması gerekir.

Raporu yalnızca PaymentDate'e göre sıralıyorsan ve aynı saniyede birden fazla ödeme düşmüşse (ödeme sisteminde sık olur), veritabanı eşit satırları sorgudan sorguya farklı sırada döndürebilir. Ana sorgu 20. sıraya A ödemesini koyar, iade sorgusu B'yi. Bir ödemenin iadeleri boş gelir ya da sayfada olmayan bir ödemenin iadeleri yüklenir. Hata almazsın, rapor sessizce yanlış olur.

EF Core 10 bu konuda bir adım attı: sıralama tekil değilse primary key'i ORDER BY'a kendisi ekliyor (dotnet/efcore#26808). Ama birkaç hafta önce açılan #39206 numaralı kayda göre bir durumda düzeltme işlemiyor: split query, projeksiyon, Skip/Take ve projeksiyonda bir tekil ilişki (p.Merchant.Name gibi) bir aradaysa sayfalama alt sorgusunda key yine yok ve bazı satırların koleksiyonları boş geliyor. Bu tarif bizim rapora birebir uyuyor.

Hangi sürümde olursan ol, sıralamanın sonuna ThenBy(p => p.Id)'yi elle yaz. Hiçbir bedeli yok ve sürümün ne yaptığını düşünmek zorunda kalmazsın.

.NET 8'den 10'a geçince

Biz bu süreçte .NET 8'den .NET 10'a da geçtik ve EF Core'un bazı ifadeleri SQL'e farklı çevirdiğini gördük.

Belgelenmiş bir örnek: EF Core 10'da ids.Contains(p.Id) gibi bir listeyle filtreleme artık varsayılan olarak tek bir JSON parametresi (OPENJSON) yerine ayrı ayrı parametrelerle (IN (@ids1, @ids2, ...)) çevriliyor. EF Core 10'un kırıcı değişiklikler listesinde "düşük etkili" diye geçiyor; ama rapor filtresinde binlerce id gönderiyorsan SQL Server'ın parametre sınırına yaklaşabilirsin.

Ders basit: sürüm yükseltirken rapor sorgularının SQL'ine bir kez daha bak. LINQ aynı kalır, altındaki SQL değişebilir.

Excel'e alma hâlâ yavaş

Ekrandaki rapor düzeldi, ama aynı raporun Excel'e alınması hâlâ yavaş. Orada sayfalama yok: 100 bin satırın üstünde veri tek seferde isteniyor ve ToList() ile önce belleğe alınıyor, sonra dosyaya yazılıyor.

Burada iki ayrı darboğaz var ve ikisini karıştırmamak gerekiyor. Birincisi veritabanı: 20 satırlık sayfada fark edilmeyen bir tarama, 100 bin satırda kendini gösterir. Bunun için PaymentDate, Status ve birkaç kolon daha üzerinde index düşünüyoruz; filtrenin ve sıralamanın kullandığı kolonlar. İkincisi bellek: bütün sonucu ToList() ile listeye alıp sonra yazmak, satır sayısı kadar nesneyi aynı anda bellekte tutmak demek. EF Core'da AsAsyncEnumerable() sonuçları satır satır akıtır; ama bunun faydası, Excel'i yazan kütüphanenin de satır satır yazabilmesine bağlı.

Bunu henüz çözmedik.

Kendi raporunda nasıl fark edersin?

Rapor sorgunda Include görüyorsan dur ve sor: bu entity'nin tamamına gerçekten ihtiyacım var mı? Sorgunun ToQueryString() çıktısında JOIN sayısına ve SELECT'teki kolon sayısına bak. Veritabanından dönen satır sayısı ekranda gösterdiğin satır sayısından fazlaysa koleksiyonlar satırları çarpıyordur. Select içinde bir C# metodu çağırıyorsan da onu sayfalamadan sonraya al.

Raporun sorusu birkaç kolondur; sorguyu o soruya göre yaz, entity modeline göre değil.

Bu yazı ilk olarak huseyinbozdemir.com'da yayımlandı.

IDOR: ASP.NET Core'da [Authorize] neden yetmez?

Hüseyin Bozdemir — Fri, 23 Oct 2026 18:29:41 +0000

IDOR (Insecure Direct Object Reference), giriş yapmış bir kullanıcının URL'deki ya da istekteki id'yi değiştirerek kendisine ait olmayan bir kayda erişebilmesidir. Kendi yaptığım bir güvenlik testinde tam bunu gördüm: aitlik kontrolü her controller'da elle yazılmıştı ve bir endpoint'te unutulmuştu. Kimlik doğrulama kusursuz çalışıyordu. Kullanıcı giriş yapmıştı, token geçerliydi, [Authorize] yerindeydi. Ama o endpoint, istenen kaydın o kullanıcıya ait olup olmadığına hiç bakmıyordu.

IDOR, OWASP API güvenliği listesinde BOLA (Broken Object Level Authorization) adıyla birinci sırada duruyor. GET /cards/{id} isteğinde kendi kartının id'sini başka bir kartınkiyle değiştirmek yetiyor. Yani eksik olan kimlik doğrulama değil, kaynak sahipliği kontrolü; bu yazıda ona kısaca aitlik diyeceğim.

Bu yazı "id'yi kontrol et" demek için değil. Herkes id'yi kontrol etmesi gerektiğini biliyor. Asıl soru şu: bu kontrolü, yarın yeni bir endpoint yazan birinin unutamayacağı bir yere nasıl koyarsın?

Kimlik doğrulama "kimsin" der, "bu senin mi" demez

Kurumsal kart yöneten bir API'den tipik bir endpoint:

[Authorize]
[HttpGet("cards/{id:guid}")]
public async Task<IActionResult> GetCard(Guid id, CancellationToken ct)
{
    var card = await db.Cards.FindAsync([id], ct);
    return card is null ? NotFound() : Ok(CardDto.From(card));
}

[Authorize] burada tek bir soruya cevap veriyor: bu isteği atan, sistemin tanıdığı biri mi? Cevap evetse kapı açılıyor. Ama "bu kart bu kişiye mi ait?" sorusunu kimse sormuyor. Token'ı geçerli olan herkes, id'sini bildiği her kartı okuyabiliyor.

Rol ve yetki kontrolü de bu boşluğu doldurmuyor. Bizde her endpoint bir izne (permission) bağlı ve kullanıcı tipi ne olursa olsun, admin bile olsa, o izne sahip değilse endpoint'e erişemiyor. Bu iyi bir kural, ama başka bir soruya cevap veriyor: "Bu işlemi yapabilir misin?" Kart görüntüleme iznine sahip bir kullanıcı, bu izin sayesinde başkasının kartını da görebiliyorsa sorun yine orada duruyor.

Yani her istekte iki ayrı kontrol var ve ikisinin de geçmesi gerekiyor:

İşlem yetkisi: Bu kullanıcı bu işlemi yapabilir mi? (rol, permission, policy)
Kaynak aitliği: Bu kullanıcı bu kayıt üzerinde bu işlemi yapabilir mi?

Her istekte iki ayrı kontrol: Token'lı istek önce işlem yetkisi kontrolünden geçer (kullanıcı bu işlemi yapabilir mi, endpoint'in bağlı olduğu izne bakılır; geçemezse 403 döner). Sonra kaynak aitliği kontrolünden geçer (kayıt kullanıcıya ait mi, kaydın departman id'si token'daki listede mi; geçemezse 403 ya da 404 döner). İkisi de geçerse kayıt döner.

Framework'ler birincisi için hazır araç verir. İkincisi senin domain'ine ait, onu kimse senin yerine bilemez.

Aitlik tek seviyeli değildir

"Kayıt kullanıcıya ait mi" diye düşününce iş kolay görünüyor: card.UserId == currentUserId. Gerçek sistemlerde aitlik nadiren bu kadar düz.

Şöyle bir örnek düşün: şirketlere kurumsal kart veren bir sistem. Bir şirketin üç departmanı var ve her departmanın çalışanlarına verilmiş kartlar var. Her kart ayrı bir kaynak. Kurallar şöyle:

Şirket yöneticisi tüm departmanların kartlarını görebilir.
Departman yöneticisi yalnızca kendi departmanının kartlarını görebilir; aynı şirketteki başka bir departmanın kartını göremez.

Kart doğrudan kullanıcıya bağlı değil. Kart departmana ait, departman şirkete. Kullanıcı ise ya şirket adına ya da belirli bir departman adına işlem yapıyor. "Bu kart senin mi" sorusunun cevabı, kullanıcının hiyerarşide nerede durduğuna bağlı.

Bunu çözmek için token'da kullanıcının ana kaynaklarını taşımak işe yarıyor; bizde de yaklaşım bu. Örnekte bu, şirket id'si ve erişilebilen departman id'leri demek. Şirket yöneticisinin token'ında üç departmanın id'si birden bulunuyor, departman yöneticisinin token'ında yalnızca kendi departmanı. Böylece aitlik sorusu tek bir kurala iniyor: kaydın DepartmentId'si, token'daki departman listesinde var mı?

Şirket, departman ve kart aitlik hiyerarşisi: bir şirkete bağlı Departman A, B ve C var; her departmanın kendi kartları bulunuyor. Şirket yöneticisinin token'ında üç departmanın id'si de var ve tüm kartları görüyor. Departman B yöneticisinin token'ında yalnızca Departman B var ve yalnızca onun kartlarını görüyor.

public interface ICurrentUser
{
    Guid UserId { get; }
    Guid CompanyId { get; }
    IReadOnlyCollection<Guid> DepartmentIds { get; }
}

Bunun bir bedeli var ve bilerek ödemen gerekiyor: token'daki liste, token'ın ömrü boyunca sabit kalıyor. Bir kullanıcının bir departmana erişimini kaldırdığında bu değişiklik, kullanıcının elindeki token süresi dolana kadar yansımıyor. Token ömrünü buna göre kısa tutmak ya da kritik işlemlerde listeyi kaynaktan tekrar doğrulamak gerekiyor.

Her controller'a elle yazılan kontrol

Başlangıçta aitlik kontrolü her action'ın içinde elle yazılıydı:

var card = await db.Cards.FindAsync([id], ct);
if (card is null)
    return NotFound();

if (!currentUser.DepartmentIds.Contains(card.DepartmentId))
    return Forbid();

Tek başına bakınca bu kodda yanlış bir şey yok. Sorun, doğruluğunun tamamen hafızaya bağlı olması. Yüz endpoint varsa yüz kez hatırlaman gerekiyor. Yeni gelen biri, acil bir düzeltme, kopyalanıp kısaltılmış bir action: biri bir gün mutlaka atlıyor. Benim testte bulduğum da tam olarak buydu. Ortada karmaşık bir açık yoktu, sadece yazılmamış dört satır vardı.

İlk adım olarak bu kontrolü merkezi bir metoda topladık:

var card = await db.Cards.FindAsync([id], ct);
if (card is null)
    return NotFound();

accessValidator.ValidateDepartmentAccess(card.DepartmentId); // erişim yoksa exception

Tekrar azaldı, kural tek bir yerde toplandı. Ama asıl sorun yerinde duruyor: ValidateDepartmentAccess'i çağırmak yine geliştiricinin aklına kalmış. Kaydı getirmek ve kontrol etmek hâlâ iki ayrı adım ve ikincisini atlasan da kod derleniyor, test geçiyor, endpoint çalışıyor.

Kontrolü daha da merkeze, örneğin bir filter'a ya da middleware'e taşımak istediğinde ise başka bir duvara çarpıyorsun: erişilmeye çalışılan kaynağın tipini nasıl bilecek? Middleware URL'de bir Guid görüyor. O id'nin bir karta mı, bir işleme mi, bir departmana mı ait olduğunu, hangi tabloya bakacağını ve hangi alanın sahibi gösterdiğini bilmiyor.

Önerdiğim yapı: kaynak kendi sahibini söylesin

Bu sorunun cevabı, bilgiyi kontrol eden tarafa değil, kaynağın kendisine koymak. Hangi alanın sahibi gösterdiğini entity'nin kendisi söylerse, generic bir kontrol her kaynak için çalışabilir.

Marker interface

public interface IEntity
{
    Guid Id { get; }
}

public interface IDepartmentScoped : IEntity
{
    Guid DepartmentId { get; }
}

public sealed class Card : IDepartmentScoped
{
    public Guid Id { get; init; }
    public Guid DepartmentId { get; init; }
    public string HolderName { get; init; } = "";
    public bool IsFrozen { get; set; }
    // ...
}

Artık "bu kaynağın sahibi kim" sorusunun cevabı tipte yazıyor. Şirket seviyesinde sahiplenilen kaynaklar için aynı şekilde bir ICompanyScoped tanımlayabilirsin. Önemli olan, bir kaynağın hangi seviyede sahiplenildiğini derleyicinin de görebilmesi.

Tek sorguda "var mı ve senin mi"

Bu interface'in üzerine generic bir koruma yazınca, kaydı getirmek ile aitliği kontrol etmek tek bir çağrıya dönüşüyor:

public sealed class OwnershipGuard(AppDbContext db, ICurrentUser currentUser)
{
    public async Task<T> GetOwnedAsync<T>(Guid id, CancellationToken ct)
        where T : class, IDepartmentScoped
    {
        var departmentIds = currentUser.DepartmentIds;

        var entity = await db.Set<T>()
            .Where(x => x.Id == id && departmentIds.Contains(x.DepartmentId))
            .SingleOrDefaultAsync(ct);

        return entity ?? throw new ResourceNotAccessibleException(typeof(T).Name, id);
    }
}

Normal akışta kullanıcı kendi kaydını istediği için bu exception seyrek fırlar; exception'ın maliyeti seyrek durumda hissedilmez.

Controller da şu hale geliyor:

[HttpGet("cards/{id:guid}")]
public async Task<CardDto> GetCard(Guid id, CancellationToken ct)
{
    var card = await guard.GetOwnedAsync<Card>(id, ct);
    return CardDto.From(card);
}

Fark küçük görünüyor ama önemli. Eskiden kontrolü unutmak için bir satırı yazmamak yeterliydi. Şimdi kontrolü unutmak için kaydı da getirmemen gerekiyor. Kaydı getirmenin yolu guard'dan geçiyorsa, aitlik kontrolü o yolun bir parçası oluyor, ayrı bir adım olmaktan çıkıyor.

Bunu tam anlamıyla işe yaratmak için bir kural daha gerekiyor: controller'lar DbContext'e doğrudan dokunmamalı. Yoksa biri yine db.Cards.FindAsync yazar ve guard'ı hiç çağırmaz. Bunu code review'a bırakmak yerine bir mimari testle de zorlayabilirsin: "API katmanındaki hiçbir tip AppDbContext'e bağımlı olamaz" gibi bir kural.

Sorgunun yapısına da dikkat et. "Var mı" ve "senin mi" tek bir WHERE ile soruluyor. Önce kaydı getirip sonra sahibine bakmıyorsun, başkasının kaydı belleğe hiç gelmiyor. Bunun 403/404 tartışmasında da işine yarayacak bir yan etkisi var, aşağıda değineceğim.

ASP.NET Core'un resource-based authorization'ı neden yetmez

ASP.NET Core'un bu iş için kendi aracı da var: resource-based authorization. Kuralı bir AuthorizationHandler içine yazıyorsun, controller'da kaydı getirdikten sonra IAuthorizationService ile kontrol ediyorsun:

var card = await db.Cards.FindAsync([id], ct);
if (card is null)
    return NotFound();

var result = await authorizationService.AuthorizeAsync(User, card, "SameDepartment");
if (!result.Succeeded)
    return Forbid();

Kuralı tek bir yerde topladığı için iyi bir araç. Ama yapısı yukarıdaki ValidateDepartmentAccess ile aynı: önce kaydı getiriyorsun, sonra kontrolü çağırıyorsun. Çağırmayı unutursan kod yine derleniyor, endpoint yine çalışıyor. Üstelik kayıt kontrolden önce belleğe geliyor; yok ile senin değil arasındaki fark, 404 ve 403 olarak istemciye de yansıyor. Handler'ı kural sınıfı olarak kullanmaya devam edebilirsin, ama kontrolün çağrılmasını geliştiricinin hafızasına bırakmamak için kaydı getiren yolun içine koyman gerekiyor.

Global query filter neden tek başına yetmez

EF Core'da aynı işi global query filter ile de yapabilirsin. IDepartmentScoped uygulayan her entity'ye DepartmentId'yi token'daki listeyle süzen bir filtre eklersin, her sorgu otomatik olarak filtrelenir. Kâğıt üzerinde daha da güvenli görünüyor çünkü çağırmayı unutabileceğin bir şey bile kalmıyor.

Pratikte bu filtreyi son savunma hattı olarak görmek daha doğru:

Bir yerde IgnoreQueryFilters() çağrıldığında, örneğin bir admin ekranı için, filtre o sorguda tamamen devre dışı kalıyor. Bunu kodda aramak zorundasın.
Dapper ile ya da stored procedure ile yazılmış raporlama sorguları filtreyi hiç görmüyor.
Filtre görünmez çalışıyor. Kaydın neden gelmediğini anlamaya çalışan bir geliştirici önce veriyi, sonra sorguyu kontrol ediyor, filtre en son aklına geliyor.

Filtreyi açarsan zarar etmez, bir katman daha eklemiş olursun. Ama "aitlik nerede kontrol ediliyor?" sorusunun cevabı açık ve okunabilir bir yerde olmalı. O yer de kaydı getiren çağrının kendisi.

Body'deki sahip id'sine güvenme

Aitlik sadece URL'deki id ile ilgili değil. İstek gövdesi de aynı riski taşıyor:

public sealed record IssueCardRequest(Guid CompanyId, Guid DepartmentId, string HolderName);

İstemci CompanyId olarak başka bir şirketin id'sini gönderirse ne olacak? Bizde bu soru tek bir kuralla kapanıyor: body'de sahip id'si gelse bile token'daki değer esas alınır. İstemcinin gönderdiği değer ezilir.

var command = new IssueCardCommand(
    CompanyId: currentUser.CompanyId,   // body'deki değer değil
    DepartmentId: request.DepartmentId,
    HolderName: request.HolderName);

if (!currentUser.DepartmentIds.Contains(command.DepartmentId))
    throw new ResourceNotAccessibleException(nameof(Department), command.DepartmentId);

Burada iki farklı durum var. CompanyId gibi kullanıcının tek bir değeri olan alanlar doğrudan token'dan alınır, istemcinin ne gönderdiğinin önemi yoktur. DepartmentId gibi birden fazla geçerli değeri olabilen alanlar ise ezilemez, token'daki listeye karşı doğrulanır. En temizi, ezeceğin alanı request DTO'suna hiç koymamak. Ama eski bir sözleşme yüzünden alan oradaysa, ona güvenme.

Mikroservis ve kuyruk tarafı

Mikroservislerde aitlik bilgisinin yolda kaybolması kolay. Gateway token'ı doğrular ve isteği arkaya iletir. Arkadaki servis "gateway zaten kontrol etti" diye düşünebilir. Ama gateway kimlik doğrulamasını yapabilir, aitliği yapamaz: kart kaydını görmüyor, hangi departmana ait olduğunu bilmiyor. Aitlik sorusunu ancak verinin sahibi olan servis cevaplayabilir.

Bu yüzden ana kaynakları token'da taşımak burada da işe yarıyor. Kullanıcının id'si, bağlı olduğu şirket ve departman id'leri token'da olduğu için her servis, aitlik sorusunu kendi verisine karşı, başka bir servise sormadan cevaplayabiliyor.

Asenkron akışta durum biraz daha ince. Bizde aitlik kontrolü genellikle mesaj publish edilmeden önce yapılmış oluyor. Buna rağmen consumer mesajdaki id'ye körü körüne güvenmiyor. Kullanıcı bağlamı mesajla birlikte taşınıyor ve consumer, mesaj gövdesindeki sahip id'sini bu bağlamdaki değerle ezip kaynağın gerçekten var olup olmadığına bakıyor:

public sealed record UserContext(Guid UserId, Guid CompanyId, IReadOnlyCollection<Guid> DepartmentIds);

public sealed record CardFreezeRequested(Guid CardId, UserContext RequestedBy);

public sealed class CardFreezeRequestedHandler(AppDbContext db) : IMessageHandler<CardFreezeRequested>
{
    public async Task HandleAsync(CardFreezeRequested message, CancellationToken ct)
    {
        var departmentIds = message.RequestedBy.DepartmentIds;

        var card = await db.Cards
            .Where(x => x.Id == message.CardId && departmentIds.Contains(x.DepartmentId))
            .SingleOrDefaultAsync(ct);

        if (card is null)
            return; // logla; böyle bir kaynak yok ya da bu kullanıcıya ait değil

        card.IsFrozen = true;
        await db.SaveChangesAsync(ct);
    }
}

Publisher'da kontrol edilmişken bunu consumer'da tekrar yapmak gereksiz görünebilir. Ama mesaj, publish ile consume arasında bir sınırı geçiyor. Yarın aynı kuyruğa başka bir servis de mesaj atmaya başlayabilir, ya da biri bir mesajı elle yeniden kuyruğa koyabilir. Consumer'ın "bu mesaj güvenilir bir yerden geldi" varsayımı, kontrolü atlamak için yeterli bir sebep değil. Kontrol ucuz, unutulduğunda ortaya çıkan sonuç pahalı.

GUID seni korumaz

IDOR konuşulurken mutlaka biri şunu söyler: "Bizde id'ler GUID, kimse tahmin edemez." Bizde de id'ler GUID'di. Unutulmuş kontrol yine de oradaydı.

GUID'in tahmin edilmesi zor, bu doğru. Ama bir saldırganın id'yi tahmin etmesine gerek yok, bulması yeterli. GUID'ler sanıldığından çok daha fazla yere sızıyor:

URL'lerde taşındıkları için tarayıcı geçmişine, proxy ve uygulama loglarına düşüyorlar.
E-postayla ya da mesajla paylaşılan linklerin içinde dolaşıyorlar.
Destek talebine eklenen ekran görüntülerinde görünüyorlar.
Başka bir endpoint'in yanıtında ilişkili kaydın id'si olarak dönüyorlar. Bir departmanın görebildiği bir harcama kaydı, başka bir kaynağın id'sini taşıyabiliyor.

Daha önemlisi, id'nin tahmin edilemez olması tasarımın bilinçli bir güvenlik özelliği değil, bir yan etkisi. Yarın biri performans için sıralı bir id şemasına geçerse, aitlik kontrolünü GUID'e emanet ettiğin her yerde güvenliğin de onunla birlikte gider. GUID saldırıyı zorlaştırır, yetkilendirmenin yerini tutmaz.

403 mü, 404 mü?

Başkasına ait bir kayda erişilmeye çalışıldığında ne dönmeli? Bizde mimari tercih 403 Forbidden'dı. Ben 404 Not Found'un daha sağlıklı olduğunu düşünüyorum.

403, "bu kayıt var ama senin değil" demek. Yani kaydın varlığını doğruluyor. Elinde bir id listesi olan biri, hangilerinin gerçek olduğunu öğrenebiliyor. 404 ise iki durumu ayırt etmiyor: kayıt ya yok ya da senin değil. GitHub'ın, erişimin olmayan private repository'ler için 404 dönmesinin sebebi de bu.

Aslında asıl sızıntı 403 ya da 404 seçiminde değil, bu ikisinin farklı durumlarda dönmesinde. Var olmayan kayda 404, başkasının kaydına 403 dönen bir API, ikisinin farkını açıkça söylüyor. Yukarıdaki GetOwnedAsync tek sorguyla çalıştığı için iki durumu zaten ayırt edemiyor ve ikisine de aynı yanıtı dönüyor. Hangi kodu seçtiğin, tutarlı olmaktan daha az önemli.

404'ün de bir bedeli var. İstemci ya da destek ekibi "kayıt yok mu, yoksa yetkim mi yok?" ayrımını yanıttan yapamıyor. Bu ayrımı API yanıtında değil, sunucu tarafındaki logda tutman gerekiyor. Logda gerçek sebebi açıkça yaz, istemciye ise genel yanıtı dön.

Kendi API'ni nasıl test edersin

İki kullanıcıyla giriş yap. A'nın kaydının id'sini B'nin token'ıyla iste ve 404 bekle. Bunu elle bir kez yapmak açığı bulur; integration testlerine her endpoint için ekleyince açığın geri gelmesini de engeller.

Okura kalan

[Authorize] ve rol kontrolü "bu işlemi yapabilir misin" sorusunu cevaplar. "Bu kayıt senin mi" ayrı bir soru ve onu ayrıca sorman gerekir.
Aitlik kontrolünü her endpoint'e elle yazarsan bir gün biri unutur. Kontrolü, kaydı getiren çağrının parçası yap ki unutmak için kaydı da getirmemek gereksin.
Kaynağın sahibini entity'nin kendisine söylet (IDepartmentScoped). Generic bir kontrol ancak tipi tanıyabilirse çalışır.
Body'deki ve kuyruk mesajındaki sahip id'lerine güvenme. Tek değerli olanları token'dan al, çok değerli olanları token'a karşı doğrula.
GUID id'yi bulmayı zorlaştırır, yetkilendirmenin yerini tutmaz. 403 ya da 404, hangisini seçersen seç, iki durumu birbirinden ayırt ettirme.
Daha fazlası için: OWASP IDOR Prevention Cheat Sheet.

Bu yazı ilk olarak huseyinbozdemir.com'da yayımlandı.

Idempotency nedir? Ödemede para iki kez çekilmesin

Hüseyin Bozdemir — Fri, 23 Oct 2026 18:29:36 +0000

Bir kullanıcı fatura ödemek için butona iki kez bastı. İki istek de bankaya gitti. Banka ilkini işledi, ikincisini aynı fatura zaten ödendiği için reddetti. Para bir kez çekildi. Teknik olarak her şey yolundaydı. Kullanıcının ekranında kalan son mesaj ise ikinci isteğin cevabıydı: işlem başarısız. Parası çekilmişti ama ödemesinin geçmediğini düşündü.

Kısa cevap: idempotency, aynı istek bir kez de gelse on kez de gelse sistemde bıraktığı etkinin aynı kalmasıdır. Ödeme API'lerinde bundan bir adım fazlası beklenir: ikinci isteğin, ilk isteğin cevabını da alması. Bunu istemcinin her ödeme niyeti için ürettiği bir idempotency key sağlar.

Bu olay bana idempotency'nin yarısını bildiğimizi gösterdi. İlk yarısı, yani paranın bir kez çekilmesi, bankanın sayesinde tutmuştu. İkinci yarısı hiç yoktu. Paranın bir kez çekilmesini sağlamak işin kolay tarafı. Zor olan, ikinci isteğe doğru cevabı verebilmek ve bankadan hiç cevap gelmediğinde ne yapacağını bilmek.

Idempotency nedir, tekrarı reddetmekten farkı ne

Idempotency, bir işlemin bir kez de yapılsa birden fazla kez de yapılsa sistemde aynı etkiyi bırakmasıdır. HTTP tarafında bu kavram zaten tanımlı: RFC 9110'a göre GET, PUT ve DELETE idempotent, POST değil. Ödeme başlatmak neredeyse her zaman bir POST. Yani protokol sana bir garanti vermiyor; idempotency'yi senin kurman gerekiyor.

Aynı ödeme isteği ikinci kez geldiğinde bir sistem üç şekilde davranabilir:

İkinci istek geldiğinde	Para	Kullanıcının gördüğü
Hiç koruma yok	İki kez çekilir	İki başarılı ödeme
Tekrar reddedilir	Bir kez çekilir	Hata mesajı
Idempotency key ile	Bir kez çekilir	İlk ödemenin sonucu

Benim hikâyemdeki banka ikinci satırdaydı. HTTP'nin tanımıyla bu davranış idempotent sayılır: RFC 9110 yalnızca isteğin sunucudaki etkisine bakar, cevabın aynı olmasını şart koşmaz. DELETE de idempotenttir, ama ikinci çağrı 404 dönebilir.

Ödeme API'lerinde bu yetmiyor. Stripe ve IETF taslağı, tamamlanmış bir isteğin tekrarına ilk işlemin sonucunun dönülmesini bekliyor; başarılı da olsa hata da olsa. Tekrarı reddetmek etkiyi korur, kullanıcıyı korumaz. Kullanıcı açısından "ödemen alınamadı" ile "ödemen zaten alındı" arasında büyük fark var ve ikinci isteğe ilkinin sonucunu dönmeyen bir sistem bu farkı kullanıcıya bırakıyor.

Tekrar nereden gelir

Çift tıklama en görünür kaynak, ama tek kaynak değil. Kullanıcı bir kez bassa bile aynı ödeme sistemin içinde birkaç yerde çoğalabiliyor:

Kullanıcı: Butona iki kez basıyor ya da sayfa yanıt vermiyor diye yeniliyor.
İstemci: Mobil uygulama ya da frontend, cevap gelmeyince isteği kendiliğinden tekrar deniyor.
Ara katman: Gateway ya da load balancer, arkadaki servisten cevap alamayınca isteği başka bir instance'a yeniden gönderiyor.
Mesaj kuyruğu: Consumer mesajı işledi ama ack göndermeden çöktü. Broker mesajı tekrar teslim ediyor.
Arka plan işleri: Hangfire'da hata alan job otomatik olarak yeniden çalışıyor.

Her katmanın tekrar denemesi kendi açısından doğru bir karar. Sorun, bu kararların hepsinin aynı para hareketine dokunabilmesi. Bu yüzden korumayı tek bir katmana koyup rahatlamak işe yaramıyor.

Kilit tekrarı durdurur, sonucu vermez

Olaydan sonra ilk yaptığımız şey, aynı faturaya aynı anda iki ödemenin girmesini engellemekti. Fatura üzerinden bir Redis lock koyduk. İkinci istek kilidi bekliyor, kilit açılınca veritabanında bu fatura için ödeme olup olmadığına bakıyor ve varsa isteği reddediyor:

[HttpPost("invoices/{invoiceId:guid}/payments")]
public async Task<IActionResult> Pay(Guid invoiceId, CancellationToken ct)
{
    await using var _ = await locks.AcquireAsync($"invoice-payment:{invoiceId}", wait: TimeSpan.FromSeconds(30), ct);

    var alreadyPaid = await db.Payments.AnyAsync(
        p => p.InvoiceId == invoiceId && p.Status != PaymentStatus.Failed, ct);

    if (alreadyPaid)
        return Conflict("Bu fatura için ödeme zaten var.");

    var payment = await payments.StartAsync(invoiceId, ct);
    return Ok(PaymentDto.From(payment));
}

Kilit iki isteği sıraya koyuyor, veritabanı kontrolü ikincisini durduruyor. Bankaya artık tek istek gidiyor ve kullanıcının "başarısız" sanma sorunu çözüldü.

Ama sorun başka bir kılığa girdi. İkinci istek kilidi beklediği için kullanıcının ekranında yükleniyor işareti uzun süre döndü ve kullanıcı bu sefer işlemin uzun sürdüğünü sandı. Kilit tekrarı durduruyor ama ikinci isteğe söyleyecek bir şeyi yok. Bildiği tek şey "bu fatura için zaten bir ödeme var".

Kilidin bir de kendi sınırları var. Süresi işlemden kısa kalırsa kilit sen işlemi bitirmeden açılıyor. Redis'e ulaşılamazsa koruma tamamen ortadan kalkıyor. Bu yüzden kilidi bir hızlandırıcı, asıl garantiyi ise veritabanı kısıtı olarak görmek gerekiyor. Ona aşağıda geleceğim.

Idempotency key: ikinci istek ilkinin sonucunu alsın

Bu yüzden kilidin üstüne bir katman daha koyduk: idempotency key. Kilit aynı faturaya iki ödemenin girmesini engellemeye devam ediyor; anahtar ise ikinci isteğe doğru cevabı veriyor.

Fikir basit. İstemci her ödeme niyeti için benzersiz bir anahtar üretiyor ve isteği Idempotency-Key başlığıyla gönderiyor. Kullanıcı butona iki kez basarsa ya da istemci isteği tekrar denerse anahtar aynı kalıyor. Sunucu bu anahtarı, isteğin özetini ve sonunda verdiği cevabı saklıyor. Aynı anahtar tekrar geldiğinde işlemi yeniden yapmıyor, sakladığı cevabı dönüyor.

Bunun için IETF'te bir standart taslağı var ve Stripe gibi ödeme sağlayıcıları yıllardır bu şekilde çalışıyor. Anahtarın ömrü sınırsız olmak zorunda değil; Stripe anahtarları en az 24 saat sonra silinebilir sayıyor.

Bir istek geldiğinde sunucunun dört durumu ayırt etmesi gerekiyor:

Anahtar ilk kez geliyor: Kaydı "işleniyor" olarak ekle, ödemeyi yap, cevabı kaydet.
Anahtar tamamlanmış: İşlemi yapma, kaydedilmiş cevabı dön. Çift tıklayan kullanıcı ilk ödemenin sonucunu görüyor.
Anahtar hâlâ işleniyor: İlk istek bitmedi. 409 Conflict dön; istemci biraz sonra aynı anahtarla tekrar sorar.
Anahtar aynı ama istek farklı: Aynı anahtar başka bir tutarla gelmiş. 422 dön; bu bir tekrar değil, istemci hatası.

ASP.NET Core'da bunu bir action filter olarak yazabilirsin:

public sealed class IdempotencyFilter(AppDbContext db, ICurrentUser currentUser) : IAsyncActionFilter
{
    public async Task OnActionExecutionAsync(ActionExecutingContext context, ActionExecutionDelegate next)
    {
        string? key = context.HttpContext.Request.Headers["Idempotency-Key"];
        if (string.IsNullOrWhiteSpace(key))
        {
            context.Result = new BadRequestObjectResult("Idempotency-Key başlığı zorunlu.");
            return;
        }

        var record = new IdempotencyRecord(currentUser.UserId, key, Fingerprint(context.ActionArguments));
        db.IdempotencyRecords.Add(record);

        try
        {
            await db.SaveChangesAsync(); // (UserId, Key) unique: aynı anda gelen ikinci istek burada düşer
        }
        catch (DbUpdateException ex) when (ex.InnerException is PostgresException { SqlState: PostgresErrorCodes.UniqueViolation })
        {
            db.Entry(record).State = EntityState.Detached;
            var existing = await db.IdempotencyRecords.SingleAsync(r => r.UserId == currentUser.UserId && r.Key == key);

            context.Result = existing switch
            {
                _ when existing.Fingerprint != record.Fingerprint => new UnprocessableEntityObjectResult("Bu anahtar farklı bir istekle kullanılmış."),
                { CompletedAt: null } => new ConflictObjectResult("İlk istek hâlâ işleniyor."),
                _ => new ContentResult { StatusCode = existing.StatusCode, Content = existing.ResponseBody, ContentType = "application/json" },
            };
            return;
        }

        var executed = await next();

        if (executed.Result is ObjectResult { StatusCode: < 500 } result)
            record.Complete(result.StatusCode.Value, JsonSerializer.Serialize(result.Value));
        else
            db.IdempotencyRecords.Remove(record); // kendi hatamız: istemci aynı anahtarla tekrar deneyebilsin

        await db.SaveChangesAsync();
    }

    private static string Fingerprint(IDictionary<string, object?> args) =>
        Convert.ToHexString(SHA256.HashData(JsonSerializer.SerializeToUtf8Bytes(
            args.Where(a => a.Value is not CancellationToken).ToDictionary())));
}

Kodda birkaç karar var ve her biri bilerek verilmeli:

Anahtar kullanıcıyla birlikte saklanıyor. Unique kısıt (UserId, Key) üzerinde. Yalnızca anahtara bakarsan, başka bir kullanıcının anahtarını bilen biri onun ödeme cevabını alabilir. Bu da başka bir kılıkta IDOR olur.
Eşzamanlılığı kısıt çözüyor, kontrol değil. "Önce bak, yoksa ekle" yazarsan aynı anda gelen iki istek ikisi de "yok" görür. Ekleyip kısıtın patlamasını beklemek, iki isteği veritabanının sıraya koymasını sağlıyor.
Hangi cevabın saklanacağı domain kararı. Banka ödemeyi reddettiyse bu ödemenin sonucu; saklanır ve aynı anahtarla gelen herkes aynı reddi görür. Bizim servisimiz çöktüyse bu bir sonuç değil; kayıt silinir ve istemci tekrar deneyebilir.

Anahtarın istemcide nerede üretildiği de önemli. Butona her basışta yeni anahtar üretirsen hiçbir şey kazanmazsın. Anahtar, ödeme ekranı açılırken bir kez üretilmeli ve o ödeme niyetinin bütün denemelerinde aynı kalmalı.

NuGet'te bunu hazır yapan paketler de var. Kullanabilirsin, ama yukarıdaki üç kararı paket senin yerine veremez. Hangisini nasıl verdiğine bakmadan eklersen, hata cevaplarını da saklayan ve kullanıcıyı sonsuza dek aynı hataya kilitleyen bir sistem kurabilirsin.

Consumer tarafı: aynı mesaj iki kez gelirse

API katmanı istemciden gelen tekrarı çözüyor. Ödeme bir kuyruğa düştükten sonra ise tekrar başka yerden geliyor: RabbitMQ gibi broker'lar mesajı "en az bir kez" teslim eder. Consumer bankayı çağırıp ack göndermeden çökerse aynı mesaj tekrar gelir.

Literatürde buna idempotent consumer deniyor ve genelde işlenen mesajları tutan ayrı bir inbox tablosuyla anlatılıyor. Bizde ayrı bir tablo yok; işin kendi durumu ve bir unique constraint aynı işi görüyor.

Durum kontrolünün tek bir tuzağı var: önce okuyup sonra yazarsan iki consumer aynı anda "Oluşturuldu" görür ve ikisi de bankayı çağırır. Kontrolü okuma ve yazma olarak değil, tek bir koşullu update olarak yapmak gerekiyor:

public async Task HandleAsync(PaymentRequested message, CancellationToken ct)
{
    var claimed = await db.Payments
        .Where(p => p.Id == message.PaymentId && p.Status == PaymentStatus.Created)
        .ExecuteUpdateAsync(s => s.SetProperty(p => p.Status, PaymentStatus.SentToBank), ct);

    if (claimed == 0)
        return; // başka bir consumer almış ya da zaten işlenmiş

    var payment = await db.Payments.SingleAsync(p => p.Id == message.PaymentId, ct);
    await bank.PayAsync(payment.Reference, payment.Amount, ct);
    // ...
}

ExecuteUpdateAsync etkilenen satır sayısını döndürüyor. Satırı yalnızca bir consumer "Oluşturuldu"dan "Bankaya iletildi"ye çekebiliyor; diğeri sıfır alıp çıkıyor.

Unique constraint ise son savunma hattı. Aynı fatura için başarısız olmamış tek bir ödeme olabilir:

builder.HasIndex(p => p.InvoiceId)
    .IsUnique()
    .HasFilter("\"Status\" <> 'Failed'");

Kilit atlansa, filter yanlış yazılsa, consumer'da bir hata olsa bile veritabanı aynı faturaya ikinci bir canlı ödeme yazılmasına izin vermiyor. Filtredeki Failed istisnası da önemli: başarısız bir ödemeden sonra kullanıcı aynı faturayı tekrar ödeyebilmeli.

Banka timeout'u: sonucu bilinmeyen çağrı

Buraya kadarki her şey, bizim kendi veritabanımızın sınırları içinde çalışıyor. Banka çağrısı bu sınırın dışında. İstek gitti, cevap gelmedi. Para çekildi mi? Bilmiyorsun.

İlk refleks bu ödemeyi başarısız kaydetmek oluyor. Ama yukarıdaki unique constraint'e bak: başarısız ödeme kısıtın dışında. Ödemeyi başarısız kaydedersen kullanıcı aynı faturayı tekrar ödeyebilir. Banka ilk isteği aslında işlediyse para iki kez çekilir. Timeout'u başarısızlık saymak, bütün koruma katmanlarını kendi elinle açmak demek.

Bu yüzden bizde ödeme bankaya gönderildiği anda "Bankaya iletildi" durumuna geçiyor ve sonuç gelene kadar orada kalıyor. Banka cevap verirse ödeme Başarılı ya da Başarısız oluyor. Cevap gelmezse arka planda 15 dakikada bir çalışan bir Hangfire job'ı bekleyen ödemeleri bankaya soruyor:

Bir ödemenin durumları: Ödeme Oluşturuldu durumunda başlar. Bankaya gönderilince Bankaya iletildi durumuna geçer; sonuç henüz bilinmiyor. Banka cevap verirse ya da periyodik durum sorgusu sonuç getirirse Başarılı ya da Başarısız olur; banka işlemi hiç bulamazsa da Başarısız olur. Cevap gelmezse ödeme Bankaya iletildi durumunda kalır ve bir sonraki sorguda tekrar sorulur.

RecurringJob.AddOrUpdate<PendingPaymentsJob>(
    "pending-payments", job => job.RunAsync(CancellationToken.None), "*/15 * * * *");

public sealed class PendingPaymentsJob(AppDbContext db, IBankGateway bank)
{
    public async Task RunAsync(CancellationToken ct)
    {
        var pending = await db.Payments
            .Where(p => p.Status == PaymentStatus.SentToBank)
            .ToListAsync(ct);

        foreach (var payment in pending)
        {
            var result = await bank.QueryAsync(payment.Reference, ct);

            if (result == BankQueryResult.Approved)
                payment.MarkSucceeded();
            else if (result is BankQueryResult.Rejected or BankQueryResult.NotFound)
                payment.MarkFailed(); // bulunamadı: istek bankaya hiç ulaşmamış
            // sonuç hâlâ belirsizse ödeme olduğu yerde kalır, bir sonraki turda tekrar sorulur
        }

        await db.SaveChangesAsync(ct);
    }
}

Sorgunun üçüncü bir cevabı daha var: banka işlemi hiç bulamayabilir. Bu, isteğin bankaya ulaşmadığı anlamına geliyor ve ödeme "alınamadı" olarak kapanıyor. Kullanıcı faturayı tekrar ödeyebiliyor, çünkü çekilmiş bir para yok. Burada güvendiğin tek şey, bankanın "bulunamadı" cevabının gerçekten "istek bana hiç gelmedi" demek olması. Bu yüzden bu cevabı her bankanın dokümanında ve testte ayrıca doğrulamak gerekiyor.

Bu sorgunun çalışabilmesi için bir şart var: bankaya giden her isteğin bizim ürettiğimiz ve tekrar denemelerde değişmeyen bir referansı olmalı. Yazının başındaki bankanın ikinci isteği reddedebilmesi de aynı fikre dayanıyordu: iki istek aynı faturayı taşıyordu. Referans, banka tarafındaki idempotency key'in ta kendisi.

Bu durumu kullanıcıya da dürüstçe göstermek gerekiyor. "Bankaya iletildi" durumundaki bir ödeme için kullanıcıya "başarısız" değil, "sonuç bekleniyor" demek gerekiyor. Aksi hâlde yazının başındaki kullanıcıyı bu kez kendi elinle yaratırsın.

Kendi sisteminde nasıl test edersin

Idempotency'yi elle test etmek zor, çünkü tekrarlar zamanlamaya bağlı. Birkaç integration testi bu açıkları önceden yakalar:

Aynı ödeme isteğini Task.WhenAll ile aynı anda iki kez gönder. Veritabanında tek ödeme olmalı, banka sahtesi bir kez çağrılmalı ve iki cevap aynı olmalı.
Aynı Idempotency-Key ile farklı tutar gönder. 422 bekle.
Consumer'a aynı mesajı iki kez ver. Banka sahtesi bir kez çağrılmalı.
Banka sahtesini timeout verecek şekilde ayarla. Ödeme "Bankaya iletildi"de kalmalı, başarısıza düşmemeli ve aynı fatura için yeni bir ödeme açılamamalı.

Okura kalan

Tekrarı reddetmek etkiyi korur, kullanıcıyı korumaz. İkinci istek, ilk isteğin sonucunu dönmeli; yoksa kullanıcı parası çekilmiş bir ödemeyi başarısız sanır.
Tekrar tek bir yerden gelmiyor. Kullanıcı, istemci, gateway, broker ve arka plan işleri ayrı ayrı tekrar dener; her katmanın kendi koruması olmalı.
Kilit tekrarı sıraya koyar, cevap vermez. Asıl garanti veritabanındaki unique constraint'te; idempotency key ise ikinci isteğe doğru cevabı verir.
Durum kontrolünü okuma ve yazma olarak değil, tek bir koşullu update olarak yap.
Timeout bir sonuç değil. Cevabı gelmeyen ödemeyi başarısız kaydetme; sonuç bilinene kadar ara bir durumda tut ve sor.

Bu yazı ilk olarak huseyinbozdemir.com'da yayımlandı.

C# exception performansı: .NET 10 ölçümü

Hüseyin Bozdemir — Fri, 23 Oct 2026 18:29:27 +0000

"Exception pahalıdır, akış kontrolünde kullanma." Bu cümleyi ilk kez bir söyleşide duymuştum; arkasından gelen öneri de belliydi: hata durumunda exception fırlatma, sonuç döndür, yani Result pattern. Ama "ne kadar pahalı" sorusuna kimse sayı vermiyordu, ben de ölçtüm.

Kısa cevap: try/catch bloğunun kendisi neredeyse bedava. Pahalı olan exception fırlatmak: .NET 10'da tek bir throw ve catch, aynı durumu dönüş değeriyle bildirmekten yaklaşık 1.300 kat yavaş. Yine de mutlak değer mikrosaniye düzeyinde; hata seyrekse bunu hissetmezsin.

Ölçüm düzeneği

BenchmarkDotNet 0.15.8, .NET 10.0.1, Windows 11, AMD Ryzen 7 5700X. Ölçümün özü şu iki metot:

[Benchmark(Baseline = true)]
public int SonucDon() => SonucIle(Derinlik).Kod;

[Benchmark]
public int FirlatYakala()
{
    try { return Firlat(Derinlik); }
    catch (InvalidOperationException) { return -1; }
}

Derinlik, hatanın kaç metot aşağıda oluştuğunu belirliyor (1 ve 10). JIT ara metotları birleştirip sonucu çarpıtmasın diye hepsi [MethodImpl(MethodImplOptions.NoInlining)] ile işaretli. Ölçüm kodunun tamamı ve ham sonuçlar GitHub'da.

try/catch performansı düşürür mü?

Hata hiç oluşmadığında:

	Süre
try/catch yok	0,24 ns
try/catch var	0,91 ns

Fark bir nanosaniyenin altında. .NET'te try bloğu her çalıştığında ek bir iş yapılmaz; hangi kod aralığının hangi catch'e ait olduğu bir tabloda durur ve bu tabloya ancak exception fırlatıldığında bakılır. Kalan 0,7 ns, bir veritabanı sorgusunun ya da HTTP isteğinin yanında ölçülemeyecek kadar küçük.

Exception fırlatmanın maliyeti

Hata oluştuğunda tablo değişiyor:

Hatanın derinliği	Sonuç döndürmek	throw + catch	Ayrılan bellek
1 metot	1,1 ns	1.491 ns	320 B
10 metot	11,2 ns	3.820 ns	1.336 B

Exception fırlatıldığında runtime bir nesne oluşturur, uygun catch'i bulmak için yığını yürür, stack trace bilgisini toplar ve aradaki her çerçeveyi geri sarar. Derinlik arttıkça bu iş büyüyor: 10 seviyede süre 2,5 katına, ayrılan bellek 4 katına çıkıyor.

Bu sayılar eskisinden iyi. .NET 9'da CoreCLR'ın exception işleme altyapısı yeniden yazıldı ve Microsoft'un mikro ölçümlerinde 2-4 kat hızlandı. Eski bir yazıda gördüğün rakamlar bugün için fazla karamsar olabilir.

Parse mı, TryParse mı?

Gündelik hayattaki karşılığı geçersiz girdi. "12a4" gibi bir metni sayıya çevirmeye çalışınca:

// 1.708 ns, 480 B
try { return int.Parse(girdi); }
catch (FormatException) { return -1; }

// 8 ns, bellek ayırmıyor
return int.TryParse(girdi, out var sayi) ? sayi : -1;

Yaklaşık 200 kat fark. Kullanıcıdan, dosyadan ya da bir HTTP isteğinden gelen girdinin hatalı olması beklenen bir durum; orada TryParse hem hızlı hem de niyeti açık.

Exception yerine Result döndürmek

Söyleşide önerilen yol buydu. En sade hali:

public readonly record struct Sonuc<T>(T? Deger, string? Hata)
{
    public bool Basarili => Hata is null;
    public static Sonuc<T> Ok(T deger) => new(deger, null);
    public static Sonuc<T> Fail(string hata) => new(default, hata);
}

public Sonuc<Siparis> Getir(int id) =>
    _depo.Bul(id) is { } siparis
        ? Sonuc<Siparis>.Ok(siparis)
        : Sonuc<Siparis>.Fail("Sipariş bulunamadı");

Bedeli de var: çağıran taraf sonucu kontrol etmek zorunda. Kontrolü unutursa hata sessizce kaybolur; exception'ın iyi yanı tam olarak bunu unutmana izin vermemesi.

Ne zaman önemli?

Mutlak sayıya bak: 1,5 µs. Saniyede 1.000 exception fırlatan bir servis bunun için saniyede yaklaşık 1,5 ms CPU harcar. Veritabanı bağlantısının kopması gibi seyrek ve beklenmeyen durumlarda exception doğru araç, maliyeti önemsiz.

Hesap, hata normal akışın parçası olduğunda değişir. Kayıt bulunamadığında exception fırlatıp middleware'de 404'e çeviren yapılar gördüm. Okunaklı görünüyor; ama "bulunamadı" sık yaşanıyorsa her istek bu bedeli öder, ayrılan bellek de GC'ye iş çıkarır. Microsoft'un exception önerileri de aynı yönde: sık yaşanan durumları exception'a bırakmadan ele al.

Kendi servisinde bakmak için dotnet-counters monitor -n <süreç-adı> System.Runtime çalıştır ve exception sayacını izle. Saniyede yüzlerce exception görüyorsan hangilerinin aslında beklenen bir sonuç olduğuna bak.

Kısa kural

try/catch yazmanın bir bedeli yok; seyrek hatada exception fırlatmak da hissedilmez.
Exception fırlatmak, sonuç döndürmekten yüzlerce kat yavaş ve bellek ayırıyor; sık yaşanan durumlarda bu fark birikir.
Beklenen sonuçlar (geçersiz girdi, bulunamadı, doğrulama hatası) dönüş değeriyle, beklenmeyenler exception'la.

Bu yazı ilk olarak huseyinbozdemir.com'da yayımlandı.

IMemoryCache mi, HybridCache mi?

Hüseyin Bozdemir — Fri, 23 Oct 2026 18:29:19 +0000

Yalnızca bellek içi cache kullanan bir sistemde banka listesi gibi nadiren değişen bir verinin sunucudan sunucuya farklı olduğunu gördüm: bir ekranda eksik, diğerinde fazla banka. Normalde veri değiştiğinde ilgili key'in cache'ten silinmesi lazım. Ama silme yalnızca değişikliği yapan sunucuda oluyor; TTL de yoksa diğerleri eski listeyi süresiz tutuyor. Bu durum pub/sub'a geçmeden çözülemedi.

Bellek içi cache'in (IMemoryCache) birden fazla sunucuda iki ayrı derdi var. Biri bu: her sunucu kendi kopyasını tutuyor ve kopyalar birbirinden habersiz. Diğeri daha sessiz: kaydın süresi dolduğu anda herkesin aynı anda veritabanına koşması (cache stampede). HybridCache, .NET 9 ile gelen, bellek içi ve dağıtık cache'i tek API'de birleştirip stampede'e karşı koruma sunan yeni soyutlama; ikinci derdi çözmek için geldi. Hangisini ne kadar çözdüğünü ölçtüm.

Cache boşaldığında herkes veritabanına koşar

Popüler bir kaydın süresi dolduğu anda o kaydı isteyen herkes cache'i boş bulur ve aynı sorgu için hep birlikte veritabanına gider. Buna cache stampede (izdiham) deniyor; İngilizce kaynaklarda "thundering herd" diye de geçer. IMemoryCache.GetOrCreateAsync buna karşı koruma sunmuyor: aynı anahtar için gelen her istek kendi sorgusunu çalıştırıyor.

Ölçüm düzeneği: her sorgusu 50 ms süren, aynı anda en fazla 100 bağlantıya izin veren sahte bir veritabanı (SqlClient ve Npgsql'de varsayılan havuz boyutu 100). Aynı anahtara, cache boşken eşzamanlı istek gönderdim. .NET 10, Microsoft.Extensions.Caching.Hybrid 10.10.

İstek	IMemoryCache	HybridCache
100	100 sorgu, 63 ms	1 sorgu, 61 ms
1.000	1.000 sorgu, p99 612 ms	1 sorgu, 53 ms
5.000	5.000 sorgu, p99 2,9 sn	1 sorgu, 64 ms

100 isteğe kadar süre farkı yok; zarar, bağlantı havuzu dolunca başlıyor. Ondan sonra gecikme istek sayısıyla birlikte doğrusal büyüyor.

Daha gerçekçi senaryo sürekli trafik: 200 kullanıcı 10 saniye boyunca istek atıyor, kayıt 1 saniyede bir doluyor. IMemoryCache her süre dolmasında veritabanına ortalama 180 kez gitti, HybridCache 1 kez.

HybridCache neyi çözüyor, neyi çözmüyor?

Kurulumu iki satır; GetOrCreateAsync aynı anahtar için gelen eşzamanlı istekleri tek sorguda birleştiriyor:

builder.Services.AddHybridCache();

public class ProductService(HybridCache cache, AppDbContext db)
{
    public async Task<Product?> GetAsync(int id, CancellationToken ct) =>
        await cache.GetOrCreateAsync(
            $"product:{id}",
            async token => await db.Products.FindAsync([id], token),
            cancellationToken: ct);
}

Bir IDistributedCache (ör. Redis) kayıtlıysa onu ikinci katman olarak kendisi kullanıyor. Ama baştaki banka listesi problemini çözmüyor. Microsoft'un dokümanı bunu açıkça söylüyor: bir kaydı anahtarla ya da tag ile sildiğinde silme o sunucuda ve Redis'te gerçekleşiyor, diğer sunucuların belleğindeki kopya etkilenmiyor.

Bunu da ölçtüm. İki HybridCache örneği (A ve B sunucusu) ortak bir ikinci katmanı paylaşıyor. İkisi de banka listesini önbelleğe alıyor, veritabanında liste değişiyor, A kaydı siliyor:

Bellek ömrü	Silme	B güncel listeyi görüyor
5 sn	anahtarla	5 sn sonra
30 sn	anahtarla	30 sn sonra
30 sn	tag ile	30 sn sonra
TTL yok (`IMemoryCache`)	anahtarla	hiç

A silmeden hemen sonra yeni listeyi görüyor; B ise bellek katmanının ömrü dolana kadar eski listeyi göstermeye devam ediyor. HybridCache bizim yaşadığımız "süresiz eski" durumunu "en fazla N saniye eski"ye çeviriyor, ama sıfırlamıyor. İzdiham koruması da aynı şekilde sunucu başına; 5 sunucun varsa veritabanına 1 değil, en fazla 5 sorgu gider.

Yani bizim pub/sub ihtiyacımız HybridCache'le ortadan kalkmazdı. Bunu hazır çözen bir seçenek olarak FusionCache'in backplane'i silme mesajını Redis pub/sub üzerinden bütün sunuculara dağıtıyor. HybridCache'te ise bellek katmanının süresini (LocalCacheExpiration) kısa tutarak eski veriyle yaşanacak süreyi sınırlıyorsun.

Gizli maliyet: her okumada deserialize

Ölçerken beklemediğim bir şey çıktı; açıkçası ben de bilmiyordum. Kayıt zaten bellekteyken okumanın bedeli:

Okuma	Süre	Bellek ayırma
`IMemoryCache.TryGetValue`	28 ns	0
HybridCache, `{ get; set; }` özellikli sınıf	520 ns	120 B
HybridCache, `sealed` + `[ImmutableObject(true)]`	43 ns	0

HybridCache değiştirilebilir (mutable) bir tipi bellekte tutsa bile her okumada yeniden deserialize ediyor. Sebebi güvenlik: iki istek aynı nesneyi alıp biri değiştirirse cache bozulur. Microsoft varsayılanı bu yüzden temkinli seçmiş. Tip sealed ve [ImmutableObject(true)] ile işaretliyse aynı nesneyi döndürüyor ve fark 18 kattan 1,5 kata iniyor:

[ImmutableObject(true)]
public sealed record Product(int Id, string Name, decimal Price);

Hangisini seçmeli?

Tek sunucu, seyrek değişen veri: IMemoryCache yeter. Popüler anahtarların süresi aynı anda doluyorsa izdihama dikkat et.
Birden fazla sunucu: tutarlılık için ya ortak bir katman (Redis) ya da silme mesajını herkese ulaştıran bir mekanizma (pub/sub, backplane) gerekiyor. HybridCache tek başına bunu vermiyor.
HybridCache'e geçiyorsan cache'lediğin tipleri sealed + [ImmutableObject(true)] yap.

HybridCache kullanamadığın eski bir projede (ör. .NET Framework'te paket eklemek istemiyorsan) izdiham korumasını IMemoryCache üzerine kendin de kurabilirsin. Ölçümdeki elle yazılmış sürüm, HybridCache'le aynı sonucu verdi (1.000 istekte 1 sorgu):

public sealed class TekSorguCache(IMemoryCache cache)
{
    private readonly ConcurrentDictionary<string, Lazy<Task<object>>> _bekleyenler = new();

    public async Task<T> GetOrCreateAsync<T>(string key, Func<Task<T>> factory, TimeSpan ttl)
    {
        if (cache.TryGetValue(key, out T? value))
            return value!;

        // Aynı anahtar için yalnızca ilk istek factory'yi çalıştırır, diğerleri aynı Task'ı bekler.
        var lazy = _bekleyenler.GetOrAdd(key, k => new Lazy<Task<object>>(async () =>
        {
            try
            {
                var result = await factory();
                cache.Set(k, result, ttl);
                return result!;
            }
            finally
            {
                _bekleyenler.TryRemove(k, out _);
            }
        }));

        return (T)await lazy.Value;
    }
}

Bütün senaryoların kodu ve ham sonuçlar GitHub'da; kendi makinende dotnet run -c Release -- soguk 1000 ile tekrarlayabilirsin.

Bu yazı ilk olarak huseyinbozdemir.com'da yayımlandı.