DEV Community: Hüseyin Bozdemir

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);
    }
}

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ü.

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ı. 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#'ta exception pahalı mı? .NET 10 ölçümleri

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ı.

Outbox pattern nedir? Kuyruk yokken outbox

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

Kullanıcılara mail ve bildirim göndermek gibi işleri isteğin içinde, senkron yapıyorduk. Kullanıcı, işlemi bitse bile mail sunucusunun cevabını da bekliyordu. Bu işleri arka plana almanın klasik cevabı bir mesaj kuyruğudur. Bizim kuyruk altyapımız yoktu ve ilk aşamada RabbitMQ istenmedi. Elimizde bir veritabanı ve birkaç sunucu vardı.

Çözüm, kuyruğu veritabanının içine koymak oldu. Yapılacak işi, işlemin kendisiyle aynı transaction'da bir tabloya satır olarak yazdık, isteği bitirdik. Arkada çalışan BackgroundService'ler o tabloyu okuyup işi yaptı. Literatürde bunun adı outbox pattern: gönderilecek mesajı ya da yapılacak işi, iş verisiyle aynı transaction'da bir outbox tablosuna yazmak ve ayrı bir süreçle oradan işlemek.

Bu yazıda outbox'ı genelde anlatıldığı gibi broker'ın önünde bir ara durak olarak değil, broker yokken kuyruğun kendisi olarak kullanmayı anlatacağım. Tablo kuyruk gibi davranmaya başlayınca kuyruğun dertleri de geliyor: aynı satırı iki işçinin alması, başarısız işler ve hiç tekrar denenmemesi gereken işler.

Outbox pattern nedir, hangi problemi çözer?

Outbox pattern (transactional outbox), bir işlemin yan etkisini (mesaj yayınlamak, mail göndermek, başka bir servisi çağırmak) hemen yapmak yerine, işlemle aynı veritabanı transaction'ında bir outbox tablosuna satır olarak yazmaktır. Ayrı bir işçi bu tabloyu sonradan okuyup işi yapar. İş kaydı ve outbox satırı ya birlikte kaydedilir ya hiç kaydedilmez; yan etki kaybolmaz.

Outbox'ın çözdüğü problemin adı dual write: bir işlemde iki ayrı sisteme yazman gerektiğinde, ikisinin birlikte başarılı olacağının garantisi yok. Klasik örnek veritabanı ve RabbitMQ:

db.Orders.Add(order);
await db.SaveChangesAsync(ct);
await bus.PublishAsync(new OrderCreated(order.Id), ct); // burada çökersen event kaybolur

SaveChangesAsync başarılı oldu, publish'ten hemen önce süreç çöktü. Sipariş veritabanında var, ama onu bekleyen hiçbir servis bundan haberdar değil. Sırayı tersine çevirirsen bu sefer veritabanında olmayan bir siparişin event'i yayılır.

Broker olmadan da aynı problem var. Mail göndermek de veritabanının dışında bir yan etki:

db.Orders.Add(order);
await db.SaveChangesAsync(ct);
await mailer.SendOrderConfirmationAsync(order, ct); // mail sunucusu yanıt vermezse?

Mail sunucusu yavaşsa kullanıcı onu bekler. Hata verirse ya isteği başarısız sayarsın (oysa sipariş kaydedildi) ya da hatayı yutarsın (mail hiç gitmez ve kimse bilmez).

Klasik transactional outbox bunu şöyle çözer: event'i doğrudan broker'a değil, işlemle aynı transaction'da bir outbox tablosuna yazarsın. Ayrı bir süreç (relay) tabloyu okur ve mesajı broker'a iletir. Tablo yalnızca broker'a giden yolda bir ara duraktır.

Bizde broker yoktu. O yüzden relay'in işi mesajı bir yere iletmek değil, işin kendisini yapmaktı.

Broker yokken tablo kuyruk olur: EF Core ve BackgroundService

Outbox tablosundaki her satır yapılacak bir iş. Bizim kurduğumuz yapıyı jenerik alan adlarıyla sadeleştirirsem şöyle bir şeye benziyor:

public sealed class OutboxJob
{
    public long Id { get; set; }
    public required string Type { get; set; }        // "notification.email", "payout" ...
    public required string WorkerKey { get; set; }   // bu satırı hangi işçi alacak
    public required string Payload { get; set; }     // işin JSON gövdesi
    public bool Retryable { get; set; }               // başarısız olursa tekrar denensin mi
    public OutboxStatus Status { get; set; }
    public int Attempts { get; set; }
    public DateTime CreatedAt { get; set; }
    public DateTime? NextAttemptAt { get; set; }
}

public enum OutboxStatus { Pending, Done, Failed }

İşi yazan taraf, iş kaydıyla outbox satırını aynı SaveChangesAsync içinde kaydediyor. EF Core ilişkisel veritabanlarında tek bir SaveChanges çağrısını zaten bir transaction içinde çalıştırır. Yani sipariş ve "bu siparişin mailini gönder" satırı ya birlikte yazılıyor ya hiç yazılmıyor:

db.Orders.Add(order);
db.OutboxJobs.Add(outbox.Create(
    type: "notification.email",
    payload: new OrderConfirmationEmail(order.Id, order.CustomerEmail),
    retryable: true));

await db.SaveChangesAsync(ct); // ikisi tek transaction
return Created($"/orders/{order.Id}", order.Id);

İstek burada bitiyor. Kullanıcı mail sunucusunu beklemiyor.

Tabloyu okuyan taraf bir BackgroundService. Belirli aralıklarla bekleyen satırları çekiyor, her birini türüne göre ilgili handler'a veriyor ve durumunu güncelliyor:

public sealed class OutboxWorker(
    IServiceScopeFactory scopes,
    IOptions<OutboxOptions> options) : BackgroundService
{
    protected override async Task ExecuteAsync(CancellationToken ct)
    {
        var opt = options.Value;
        using var timer = new PeriodicTimer(opt.PollInterval);

        while (await timer.WaitForNextTickAsync(ct))
        {
            await using var scope = scopes.CreateAsyncScope();
            var db = scope.ServiceProvider.GetRequiredService<AppDbContext>();
            var processor = scope.ServiceProvider.GetRequiredService<OutboxProcessor>();
            var now = DateTime.UtcNow;

            var jobs = await db.OutboxJobs
                .Where(j => j.WorkerKey == opt.WorkerKey
                         && j.Status == OutboxStatus.Pending
                         && (j.NextAttemptAt == null || j.NextAttemptAt <= now))
                .OrderBy(j => j.Id)
                .Take(opt.BatchSize)
                .ToListAsync(ct);

            foreach (var job in jobs)
                await processor.ProcessAsync(job, ct);

            await db.SaveChangesAsync(ct);
        }
    }
}

BackgroundService ASP.NET Core uygulamasının içinde, uygulamayla birlikte başlayıp duran bir işçi. Ayrı bir servis kurmana, ayrı bir altyapı işletmene gerek yok. Kuyruk altyapısı olmayan bir ekip için outbox'ı cazip yapan şey de bu: bizim için kurulumu RabbitMQ'dan daha kolaydı. Yeni bir tablo ve uygulamanın içinde birkaç sınıf.

Sorgudaki WorkerKey filtresi ise bir sonraki bölümün konusu.

Aynı satırı iki sunucu almasın

Uygulama tek sunucuda çalışıyorsa yukarıdaki döngü yeter. Birden fazla sunucuda çalışıyorsa her sunucunun BackgroundService'i aynı tabloyu okur. İki sunucu aynı anda aynı Pending satırı çekerse kullanıcıya iki mail gider.

Bu problemin yaygın çözümü satır kilidi. SQL Server'da UPDLOCK, READPAST ipuçlarıyla her işçi bekleyen satırları kilitleyerek alır, başka bir işçinin kilitlediği satırları da beklemeden atlar. PostgreSQL'de karşılığı FOR UPDATE SKIP LOCKED. İngilizce kaynakların çoğu bu yolu anlatıyor ve doğru bir yol.

Biz başka bir yol seçtik: satırları sunuculara paylaştırdık. Her outbox satırının bir WorkerKey'i var ve bu key genelde işin türüne göre belirleniyor. Her sunucunun appsettings'inde de hangi key'i okuyup işleyeceği yazıyor:

{
  "Outbox": {
    "WorkerKey": "notifications",
    "PollInterval": "00:00:05",
    "BatchSize": 50
  }
}

Bir sunucu yalnızca kendi key'ine sahip satırları görüyor. İki sunucu aynı satıra hiç bakmadığı için kilide de ihtiyaç kalmıyor. Bir sunucuya bir şey olduğunda yedek sunucuya aynı key'i veriyorduk ve onun satırlarını o devralıyordu.

Bu yapının tek bir kuralı var: aynı key aynı anda iki sunucuya asla verilmez. Biz hiç vermedik, o yüzden çift işleme yaşamadık. Ama bu garantiyi veritabanı değil, bir operasyon kuralı veriyor. Yanlış kopyalanmış bir appsettings dosyası, kilitli yaklaşımın hiç izin vermeyeceği bir çift işlemeye yol açar.

İki yaklaşımı yan yana koyarsak:

	Satır kilidi (`UPDLOCK, READPAST`)	Key ile paylaştırma
Çift işlemeyi engelleyen	Veritabanı	Yapılandırma kuralı
Bir sunucu düşerse	Diğerleri satırları alır	Yedeğe key elle verilir
Bir iş türü yoğunlaşırsa	Tüm sunucular paylaşır	O key'in sunucusu tek başına taşır
Karmaşıklık	Kilit, timeout, takılan satır	Bir `Where` koşulu

Key yaklaşımının asıl bedeli üçüncü satırda. Bir iş türü tek bir sunucuya bağlı olduğu için o türün işleri yatayda ölçeklenmiyor. Bildirim gibi hacmi öngörülebilir işlerde bu sorun olmayabilir; ani yük gelen bir iş türünde o sunucunun kuyruğu uzar ve diğer sunucular boşta bekler.

Karşılığında aldığımız şey sadelik. Kilitli yaklaşımda işçi satırı aldıktan sonra çökerse o satırın kilidinin ya da "işleniyor" durumunun nasıl çözüleceğini de tasarlaman gerekir. Key yaklaşımında böyle bir ara durum yok.

Her iş tekrar denenmez

Outbox satırının işi başarısız olabilir: mail sunucusu yanıt vermez, karşı servis hata döner. Burada en kolay karar "başarısız olanı birkaç kez daha dene" olur. Biz bunu her iş için yapmadık.

Her satırın bir Retryable bayrağı var. Tekrar denenebilecek işler bu bayrakla işaretleniyor ve hata aldıklarında bir süre sonra yeniden deneniyor. Riskli gördüğümüz para çıkışı işlemleri ise hiç tekrar denenmiyor: başarısız olunca satır Failed durumuna geçiyor ve incelenmesi için ilgili ekiplere mail gidiyor.

public async Task ProcessAsync(OutboxJob job, CancellationToken ct)
{
    try
    {
        await handlers.For(job.Type).HandleAsync(job.Payload, ct);
        job.Status = OutboxStatus.Done;
    }
    catch (Exception ex)
    {
        job.Attempts++;

        if (job.Retryable && job.Attempts < options.MaxAttempts)
        {
            job.NextAttemptAt = DateTime.UtcNow.Add(Backoff(job.Attempts));
            return; // Pending kalır, sonra tekrar alınır
        }

        job.Status = OutboxStatus.Failed;
        await alerts.NotifyTeamAsync(job, ex, ct); // bir insan baksın
    }
}

Bu ayrım bence yazının en önemli kararı. Bir bildirimi iki kez göndermenin bedeli küçük: kullanıcı aynı maili iki kez görür. Para çıkışında "başarısız" çoğu zaman "olmadı" değil, "ne olduğunu bilmiyorum" demektir. Karşı taraf işlemi yapmış ama cevabı sana ulaşmamış olabilir. Böyle bir işi otomatik olarak tekrar denemek, paranın iki kez çıkması riskini sisteme kendi elinle yazmak olur. Idempotency yazısında banka timeout'u için anlattığım durum bunun aynısı.

Bir ayrıntı daha: outbox işi "en az bir kez" yapar, "tam bir kez" değil. İşçi maili gönderip satırı Done olarak kaydetmeden önce çökerse, sunucu ayağa kalktığında satır hâlâ Pending görünür ve mail tekrar gider. Tekrar denenecek her iş, iki kez çalışmaya dayanıklı olmalı. Dayanıklı değilse ya tüketici tarafında idempotency kurarsın ya da bizim para çıkışında yaptığımız gibi hiç otomatik denemezsin.

Kendi sisteminde nasıl izlersin

Tablo kuyruğa dönüşünce kuyruğun metrikleri de sana kalıyor. RabbitMQ'nun yönetim panelinde hazır gördüğün şeyleri burada kendin sorgulaman gerekiyor. Üç sayı çoğu sorunu erkenden gösterir:

SELECT WorkerKey,
       COUNT(*)       AS Bekleyen,
       MIN(CreatedAt) AS EnEskiBekleyen
FROM OutboxJobs
WHERE Status = 0 -- Pending
GROUP BY WorkerKey;

SELECT COUNT(*) AS Basarisiz
FROM OutboxJobs
WHERE Status = 2; -- Failed

Bekleyen satır sayısı sürekli artıyorsa işçi yetişemiyor ya da hiç çalışmıyor.
En eski bekleyen satırın yaşı tek başına en iyi alarm. Polling aralığın 5 saniyeyken 10 dakikalık bir satır varsa o key'in sunucusunda bir sorun var. Key ile paylaştırmada bu özellikle önemli, çünkü bir sunucu durduğunda onun satırlarını başka kimse almıyor.
Başarısız satır sayısı artıyorsa giden mailler de artıyor demektir; o mailler gözden kaçmaya başlamadan önce sayıya bakmak gerekiyor.

İki bakım işi de unutulmamalı. Birincisi index: işçinin sorgusu her birkaç saniyede bir çalışıyor, (WorkerKey, Status, Id) gibi bir index olmazsa tablo büyüdükçe bu sorgu yavaşlar. İkincisi temizlik: Done satırlar sonsuza kadar tabloda kalırsa tablo şişer. Belirli bir süreden eski tamamlanmış satırları silen ya da arşive taşıyan bir iş gerekir.

Ne zaman RabbitMQ'ya geçmeli?

Biz sonradan hibrit bir yapıya geçtik: bazı yerlerde RabbitMQ, bazı yerlerde outbox kaldı. Outbox tablosu bir kuyruğun yerini tamamen tutmuyor, ama her iş için de kuyruk gerekmiyor.

Genel bir çerçeve çizmem gerekirse outbox tablosu şu durumlarda yetiyor: iş aynı uygulamanın içinde yapılıyor, hacim öngörülebilir ve birkaç saniyelik gecikme sorun değil. Bir event'i birden fazla servisin dinlemesi gerekiyorsa, aynı iş türünü birçok işçiye dağıtman gerekiyorsa ya da tüketicileri bağımsız ölçeklemek istiyorsan broker'ın sağladığı şeyleri tabloyla yeniden yazmaya başlarsın. Orada RabbitMQ daha ucuz.

Broker'a geçince outbox'ı atman da gerekmiyor. Klasik kullanımı tam olarak bu: veritabanı ile broker arasındaki dual write'ı kapatmak. MassTransit ve CAP gibi kütüphaneler EF Core ile çalışan hazır bir transactional outbox sunuyor. Broker'ı kurduğunda elle yazılmış relay'i bırakıp bunlardan birine geçmek çoğu zaman daha az kod demek.

Okura kalan

Arka plan işi için mesaj kuyruğu şart değil. İşi iş kaydıyla aynı transaction'da bir tabloya yazan outbox ve bir BackgroundService birçok durumda yeter.
Tablo kuyruğa dönüşünce çift işleme senin sorunun olur. Ya satır kilidiyle (UPDLOCK, READPAST / SKIP LOCKED) ya da satırları key ile sunuculara paylaştırarak çözersin. İkincisi basit ama garantisi bir yapılandırma kuralına dayanıyor.
Her işi tekrar deneme. İki kez yapılması zararsız olan işi dene. Sonucu belirsiz kalabilen para hareketini başarısız say ve bir insana göster.
Kuyruğun metriklerini artık sen tutuyorsun: bekleyen satır sayısı, en eski satırın yaşı ve başarısız satırlar.

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

Idempotency key nedir, istemcide nerede üretilir?

Hüseyin Bozdemir — Fri, 23 Oct 2026 18:28:59 +0000

Sunucuda idempotency'yi kurdun: anahtar saklanıyor, aynı anahtar gelince cevap tekrar dönüyor, kuyrukta consumer tekrarı tanıyor. Sonra istemciye baktın; ödeme butonuna her basışta yeni bir Idempotency-Key üretiliyor. Kullanıcı iki kez bastı, iki farklı anahtar gitti, sunucu ikisini de ayrı ödeme sandı. Bütün o altyapı hiçbir şeyi korumadı.

Idempotency key, istemcinin ürettiği ve sunucunun aynı işlemin tekrarını tanımasını sağlayan benzersiz anahtardır. Kısa cevap: butona basışta değil, ödeme niyeti oluştuğu anda, yani ödeme ekranı açılırken üretilir.

Bunu Idempotency yazısının sonunda tek cümleyle geçmiştim. Bu kısa not o cümlenin devamı; çünkü "nerede üretilir" sorusunun cevabı bizde de ilk başta göründüğü kadar basit çıkmadı.

Key bir isteğin değil, bir niyetin kimliği

Idempotency key, istemcinin "ben bu ödemeyi yapmak istiyorum" dediği anı temsil eden benzersiz bir değerdir. Tanımdaki önemli kelime istek değil, niyet. Bir niyet için kaç istek giderse gitsin (çift tıklama, timeout sonrası retry, ağ kopması) hepsi aynı anahtarı taşır. Sunucunun tekrarı tanıması ancak böyle mümkün olur; Stripe'ın dokümanı da anahtarı aynı mantıkla tanımlar.

Bu yüzden anahtar butonun tıklama olayında değil, niyetin doğduğu yerde üretilir. Bizde bu yer ödeme ekranının açılışı. Kullanıcı sepetini onaylayıp ödeme ekranına geldiğinde sipariş artık değişmiyor; ekran açılırken üretilen tek anahtar o siparişin bütün denemelerinde aynı kalıyor.

Ekran değişebiliyorsa

Her ödeme ekranı donmuş değil. Tutarın, taksit seçeneğinin ya da ödeme yönteminin ekranda değişebildiği akışlar var. Orada "ekran açılışı" yanlış an olur: kullanıcı taksidi değiştirir, aynı anahtarla farklı bir istek gider.

Bu durumda anahtar, ödemenin snapshot'ı alındığı anda üretilir. Snapshot, kullanıcının gördüğü ve onayladığı son halin kaydıdır; tutar ve seçenekler o anda sabitlenir, anahtar o kayda bağlanır. Sonrasında bir şey değişirse yeni bir snapshot ve yeni bir anahtar doğar.

Sunucu tarafı bu kuralın bekçisi. Aynı anahtar farklı bir istek gövdesiyle gelirse bu bir tekrar değil, istemci hatasıdır ve 422 döner. İlk yazıdaki dört durumdan biri buydu; istemci anahtarı doğru yerde üretmezse en çok bu kapıya çarpar.

Sayfa yenilenince ne olur

Anahtar istemcide bellekte duruyor. Kullanıcı sayfayı yenilerse ya da geri dönüp tekrar gelirse anahtar gider; ekran yeniden açılır ve yeni bir anahtar üretilir. İlk bakışta bu, yenilemeyle çift ödemeye kapı açıyor gibi görünür.

Bizde bunu anahtar değil, başka bir soru engelliyor. Ödeme ekranı açılırken istemci sunucuya "bu sipariş ödendi mi?" diye soruyor. İlk deneme sonuçlandıysa ekran ödeme formunu değil sonucu gösteriyor; sonuçlanmadıysa kullanıcı yeni anahtarla devam ediyor. Yani anahtar aynı niyetin tekrarlarını birbirine bağlıyor, sipariş durumu sorgusu ise niyetin ikinci kez doğmasını engelliyor. İki ayrı koruma, iki ayrı iş.

Anahtarı sessionStorage'da saklayıp yenilemeden sonra da aynı anahtarla devam etmek mümkün. Bunun bedeli, saklanan anahtarın ait olduğu siparişle hâlâ eşleşip eşleşmediğini ayrıca takip etmek. Sipariş durumunu zaten soruyorsan bu ek karmaşıklık pek bir şey kazandırmıyor; biz o yüzden saklamadık.

Kodda nasıl görünüyor

export class PaymentScreen {
  // Niyet başına bir anahtar: ekran açılırken (ya da snapshot anında) üretilir.
  private idempotencyKey = crypto.randomUUID();

  constructor(private readonly api: PaymentApi, private readonly orderId: string) {}

  async open() {
    const status = await this.api.getOrderStatus(this.orderId);
    if (status.isPaid) return this.showResult(status);
    this.showForm();
  }

  // Çift tıklama, timeout, retry: hepsi aynı anahtarla gider.
  async pay(amount: Money) {
    return this.api.charge(this.orderId, amount, { idempotencyKey: this.idempotencyKey });
  }
}

Anahtarın üretildiği satır pay metodunun içinde olsaydı her tıklamada yenilenirdi; sınıfın alanı olunca ekranın ömrü boyunca sabit kalıyor. Başlık adı için IETF'nin Idempotency-Key taslağı var; biz de aynı adı kullanıyoruz.

Kendi sisteminde nasıl fark edersin

Ödeme ekranında butona hızlıca iki kez bas ve ağ sekmesinde iki isteğin Idempotency-Key başlığına bak. Değerler farklıysa anahtar yanlış yerde üretiliyor; sunucudaki idempotency katmanı o iki isteği birbirine bağlayamaz.

Okura kalan

Anahtar niyet başına bir tane; isteğe değil, ödeme niyetine bağla.
Ekran değişebiliyorsa anahtar snapshot anında doğar, aynı anahtarla farklı istek 422 ile reddedilir.
Sayfa yenilemesine karşı korumayı anahtara yükleme; ekran açılırken sipariş durumunu sor.

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

Log maskeleme: .NET'te kart numarası sızmasın

Hüseyin Bozdemir — Fri, 23 Oct 2026 18:28:54 +0000

Kart numarasını log'a yazmadan önce regex'le maskelemek yaygın bir yöntem: her endpoint kendi log satırında maskeleme fonksiyonunu çağırır. Çağırmayı unutan tek bir endpoint olduğunda kart numarası log'a açık düşer.

Log maskeleme, hassas bir değeri log'a yazılmadan önce okunamaz hale getirmektir. Kart numarasında genelde ilk 6 ve son 4 hane kalır: 411111******1111. PCI DSS de gösterimde en fazla BIN ve son dört haneye izin veriyor (PCI SSC SSS 1492). Bu bir üst sınır; BIN 8 haneyse "ilk 6" kuralı da değişiyor, log'da daha azını göstermek daha güvenli.

Sorun maskelemenin kendisinde değil, nerede yapıldığında. Endpoint başına yapılan maskeleme, birinin hatırlamasına bağlıdır.

Bu notta maskelemeyi hatırlamaya bırakmayan bir yapı öneriyorum: kart numarasını kendi tipine sarmak, .NET'in yerleşik Microsoft.Extensions.Compliance.Redaction aracı ve log'u tarayan bir test. Örneklerin hepsini .NET 10'da küçük bir projede çalıştırıp çıktısına baktım.

Kart numarası log'a hangi yollardan düşer

Tek yol unutulan bir LogInformation satırı değil. Örnek projede şunların hepsi numarayı açık yazdı:

Nesneyi olduğu gibi loglamak. record tipinin ToString'i bütün alanları yazar; log.LogInformation("Ödeme {Istek}", istek) çıktısında KartNo = 4111111111111111 görünür, CVV de. Aynı DTO class iken yalnızca tip adı yazılıyordu; yani DTO'yu record'a çevirmek, log koduna dokunmadan sızıntı başlatıyor. Serilog'da {@Istek} aynısını JSON olarak yapar.
Exception mesajı. long.Parse("4111 1111 1111 1111") fırlattığı FormatException'ın mesajına girdinin kendisini koyar; KeyNotFoundException da aranan anahtarı yazar. Kendi kodun numarayı hiç loglamasa da LogError(ex, ...) onu log'a taşır.
Query string. GET /kart?pan=... gibi bir istek, ASP.NET Core'un kendi "Request starting" log'unda tam URL'iyle görünür. Şablonda Microsoft.AspNetCore seviyesi Warning olduğu için çoğu zaman görünmez; hata ayıklarken Information'a çektiğin gün görünür.
HttpLogging. HttpLogging middleware'inde RequestBody açıksa gövde olduğu gibi yazılır.
EF Core. EnableSensitiveDataLogging açıksa sorgu parametreleri düz yazılır: @p0='4111111111111111'. Kapalıyken '?' görünür.

Regex bunların bir kısmını yakalar, bir kısmını yakalamaz. Hangisini yakaladığını da çoğu zaman kimse bilmez.

Varsayılanı tersine çevir: kart numarası kendi tipini taşısın

Önerim kart numarasını string olarak dolaştırmamak. İstek gövdesi sınırda bir KartNo tipine bağlanır ve bu tipin ToString'i her zaman maskeli döner. Açık değer yalnızca bankaya giden istekte, adıyla çağrılan bir metotla alınır.

[JsonConverter(typeof(KartNoJsonConverter))]
public readonly struct KartNo
{
    private readonly string _deger;
    private KartNo(string deger) => _deger = deger;

    public static KartNo Parse(string girdi)
    {
        var rakamlar = new string(girdi.Where(char.IsDigit).ToArray());
        if (rakamlar.Length is < 13 or > 19 || !Luhn.Gecerli(rakamlar))
            throw new FormatException("Kart numarası geçersiz."); // değeri mesaja koyma
        return new KartNo(rakamlar);
    }

    // Açık değer yalnızca bankaya giden istekte.
    public string Acik() => _deger;

    public override string ToString() =>
        _deger is null ? "" : $"{_deger[..6]}{new string('*', _deger.Length - 10)}{_deger[^4..]}";
}

KartNoJsonConverter okurken KartNo.Parse'ı çağırıyor, yazarken ToString'i. Yani bu tipi taşıyan bir nesne yanlışlıkla JSON olarak loglansa da maskeli çıkar; bankaya giden istek ayrı bir modelde Acik() ile kurulur.

Aynı örnek projede bu tiple {KartNo}, {Istek}, string interpolasyonu ve kendi yazdığımız exception mesajı hep 411111******1111 yazdı. Endpoint'i yazan kişinin maskelemeyi hatırlaması gerekmiyor: unutursa log'a maskeli bir satır düşüyor. Açık değeri istemek ise Acik() diye ayrıca yazılması gereken, code review'da göze batan bir çağrı. IDOR yazısında aitlik kontrolü için de aynı şeyi savunmuştum: unutulabilen kontrolü unutulamaz hale getirmek.

Serilog kullanıyorsan {@Istek} içinde de ToString'in kullanılması için yapılandırmaya bir satır ekledim: .Destructure.AsScalar<KartNo>().

Hazır bir paket istersen Serilog.Enrichers.Sensitive kart numarasını regex'le maskeliyor. Ama denediğim sürüm (2.1.0) yalnızca 16 haneyi tanıdı ve Luhn kontrolü yapmadı: 15 haneli bir Amex test kartını açık bıraktı, 16 haneli bir sipariş numarasını maskeledi.

.NET'in yerleşik çözümü: Redaction

.NET'in kendi aracı Microsoft.Extensions.Compliance.Redaction. Veriyi bir attribute ile sınıflandırıyorsun, bir redactor kaydediyorsun, log pipeline'ında redaction'ı açıyorsun. Kaynak üretimli [LoggerMessage] metotlarında ve [LogProperties] ile loglanan nesnelerde iyi çalıştı.

Ama aynı logger'la yazılan klasik LogInformation("Kart {KartNo}", ...) satırı, record'un ToString'i ve exception mesajı açık kaldı. Redaction, doğru log metodunu kullanmayı hatırlamaya bağlı; yani endpoint başına regex'le aynı soruyu taşıyor. Tip yaklaşımıyla birlikte iyi bir katman, tek başına değil.

Kendi 6+4 redactor'ını yazacaksan bir ayrıntı: ApplyDiscriminator varsayılan olarak açık ve redactor'a değer yerine değer:alanAdı geliyor. Maskelenmiş çıktının sonunda kart hanesi yerine alan adının son harflerini görürsen sebep bu; kapatman gerekiyor.

Regex'in doğru yeri: son kontrol

Regex atılmaz, yeri değişir. Entegrasyon testlerinde bütün log çıktısını toplayıp kart numarasına benzeyen ve Luhn kontrolünden geçen bir dizi arayan bir kontrol, unutulan yeri prod'a çıkmadan yakalar.

public static partial class KartTarayici
{
    [GeneratedRegex(@"(?<!\d)(?:\d[ -]?){12,18}\d(?!\d)")]
    private static partial Regex Aday();

    public static bool KartVar(string satir) =>
        Aday().Matches(satir).Any(m =>
            Luhn.Gecerli(new string(m.Value.Where(char.IsDigit).ToArray())));
}

Luhn kontrolü sipariş numarası gibi 16 haneli ama kart olmayan değerlerin çoğunu eler. Örnek projede test kartı yakalandı, Luhn'dan geçmeyen 16 haneli bir sipariş numarası yakalanmadı.

Tipin göremediği iki yer için iki kural daha gerekiyor: ödeme endpoint'lerinde HttpLogging'in gövde loglaması kapalı kalır, kart numarası query string'e hiç girmez. İkisi de istek tipe bağlanmadan önce log'a düşüyor.

Regex'in ne kadar iyi yazıldığı ikinci planda kalıyor; asıl risk, birinin onu çağırmayı hatırlamasına dayanması.

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

AI'ın yazdığı testler hatayı yakalar mı? Mutation testing ile ölçüm

Hüseyin Bozdemir — Fri, 23 Oct 2026 18:28:46 +0000

Bir faturanın durumunu bankadan gelen koda göre eşleyen eski bir kod vardı. Kural kısaydı: bankadan "A" gelirse faturayı ödendi olarak işaretle. Yapay zekâya bu koda test yazdırdım; testler kurala uygun, düzgün ve yeşildi. Sonra bankada "A"nın bambaşka bir durum olduğu ortaya çıktı. Testler hatayı yakalamamıştı, üstüne bir de "doğru" diye imzalamıştı.

Kısa cevap: test kalitesini ölçen iki sayıda da, kapsamda (coverage) ve mutation skorunda (koda bilerek konan küçük hataların testler tarafından yakalanma oranı), AI'ın testleri doğru kodda tam not aldı. Koda bilerek bir hata koyduğumda da tam not aldı. Testler yeşildi, kapsam %100'dü, mutation skoru %100'dü ve hata oradaydı.

Yeni bir kodu iş kuralıyla birlikte verdiğimde AI temiz test yazıyor. Eski kodda ise kural hatalıysa test de hatalı geliyor. Bu farkın ne kadar büyük olduğunu C# ve Stryker.NET ile dört varyantta ölçtüm.

Kapsam neyi ölçer, mutation testing neyi?

Kapsam, testler çalışırken kodun hangi satırlarından ve dallarından geçildiğini sayar. Bir if'in iki kolu da çalıştıysa dal kapsamı tamdır. Ama kapsam, testin sonucu doğru kontrol edip etmediğini bilmez; hiçbir Assert içermeyen bir test de satırları "kapsar".

Mutation testing bu boşluğu kapatmak için var. Araç, kodda küçük bir değişiklik yapar (buna mutant denir), sonra testleri çalıştırır. Örneğin:

if (araToplam >= SabitKuponEsigi)   // asıl kod
if (araToplam > SabitKuponEsigi)    // mutant

Testlerden en az biri kırılırsa mutant "öldürülmüş" sayılır: testler bu değişikliği fark etmiştir. Hepsi yeşil kalırsa mutant "hayatta kalır" ve testlerinde bir kör nokta olduğunu gösterir. Mutation skoru, öldürülen mutantların oranıdır. .NET'te bunun aracı Stryker.NET; Microsoft'un dokümantasyonunda da kısa bir rehberi var.

Yaygın kanı şu: AI'ın yazdığı testler kapsamı kolayca şişirir, mutation skoru ise bunun içinin boş olduğunu ortaya çıkarır. Ben de bunu bekliyordum.

Deney

Sıfırdan küçük bir sepet hesaplayıcı yazdım. Kuralı az ama sınır değeri çok; mutation testing'in en iyi yakaladığı türden:

Ara toplam 1.000 TL ve üstündeyse %5 kademe indirimi.
YUZDE10 kuponu kalan tutarın %10'u, en fazla 200 TL.
SABIT50 kuponu 50 TL; ara toplam 250 TL ve üstündeyse geçerli.
İndirimlerden sonra 500 TL ve üstü ücretsiz kargo, altı 49,90 TL. Ağırlık 20 kg'ı aşarsa ücretsiz kargoda bile 30 TL ağır yük ücreti.
Her adım kuruşa yuvarlanır (MidpointRounding.AwayFromZero).

Testleri Claude Opus 5.5 yazdı. Her seferinde bağlamı boş yeni bir oturum açtım, yalnızca sınıfı verdim ve aynı cümleyi kullandım: "Bu C# sınıfı için xUnit testleri yaz." Testlere elle dokunmadım. Ölçüm: coverlet ile kapsam, Stryker.NET 5.0 ile mutation skoru, .NET 10 üzerinde.

Aynı sınıfı dört şekilde verdim:

Varyant	Kurallar sınıfın başındaki yorumda	Kod
A	var	doğru
B	yok	doğru
C	yok	hatalı
D	var	hatalı

Hata tek karakterlik: SABIT50 kontrolünde >= yerine >. Yani tam 250 TL'lik sepette kupon sessizce çalışmıyor. Sınırda bir birimlik kayma (off-by-one); 250,00 TL'lik sepet nadir olduğu için uzun süre fark edilmeyebilir.

Beklenti tutmadı: %100

Doğru kodda iki varyantın sonucu:

	Test sayısı	Dal kapsamı	Mutation skoru
A (kurallar yorumda)	56	%100	%100 (41/41)
B (yorum yok)	47	%100	%100 (41/41)

Hayatta kalan tek mutant yok. Testler eşiklerin hem hemen altını hem tam kendisini deniyordu: 999,99 ve 1.000; 249,99 ve 250; 499,99 ve 500; 20 kg ve 20,001 kg. Yarım kuruşu yukarı yuvarlamayı, kupondan sonra kargo kararının değiştiği durumu, ücretsiz kargoda ağır yük ücretini ayrı ayrı yakalıyordu. Çoğu test, sonucun tamamını tek seferde karşılaştırıyordu:

[Fact]
public void Sabit50_esikte_50_TL_duser()
{
    var sonuc = Hesapla(250m, "SABIT50");

    Assert.Equal(new SepetSonucu(250m, 0m, 50m, 49.90m, 249.90m, false), sonuc);
}

Bu, mutation testing açısından güçlü bir alışkanlık. Tek bir alanı kontrol eden test, diğer alanlardaki değişikliği kaçırır; record'un tamamını karşılaştıran test kaçırmaz.

B'nin sonucu beni A'dan daha çok şaşırttı. Kuralları anlatan yorumu kaldırınca da AI sınırları kodu okuyarak buldu. Yani bu modülde "AI'ın testleri yüzeysel kalır" iddiası tutmadı.

Bir yan not: coverlet'in raporunda satır kapsamı A için %79, C için %69 göründü. İkisinde de çalışan kodun tamamı kapsanıyordu. Açıkta kalan satırlar const bildirimleri ve record'un property'leriydi; testler Assert.Equal ile record'u bütün olarak karşılaştırınca getter'lar hiç çağrılmıyor. Aynı kapsamda iki test dosyası, yazım tarzı yüzünden on puan farklı sayı alabiliyor. Satır yüzdesini tek başına ölçü yapmamak için bir neden daha.

Hatayı koyunca: yeşil testler, %100 skor

C varyantında kod hatalı ve kurallar yorumda yok. AI 42 test yazdı, hepsi geçti. Dal kapsamı %100, mutation skoru %100.

AI 250 TL sınırını gördü ve test etti. Ama gördüğü davranışı doğru kabul etti:

[Fact]
public void Sabit50_esikte_uygulanmaz_ama_gecersiz_sayilmaz()
{
    Assert.Equal(Beklenen(250m, 0m, 0m, 49.90m, 299.90m), H("SABIT50", K(250m)));
}

Testin adı durumu özetliyor: "Eşikte uygulanmaz." Kuralı bilmeyen biri için bu, kodun söylediğinin dürüst bir tarifi. Kuralı bilen biri için bir hata raporu.

Asıl ilginç olan, mutation testing'in burada ne yaptığı. Stryker'ın denediği mutantlardan biri >'yi >='ye çevirmek, yani hatayı düzeltmek. Bu test o mutantı öldürüyor: biri hatayı düzeltirse test kırılıyor. Mutation testing, hatalı davranışı korumaya yardım etti. Çünkü ölçtüğü şey testlerin değişikliği fark edip etmediği; değişikliğin iyi mi kötü mü olduğunu bilemez.

Kuralı verince test kırıldı

D varyantında kod aynı şekilde hatalı ama sınıfın başında kurallar yazıyor: "ara toplam 250 TL ve üstündeyse geçerli". Bu sefer AI kuralın tarafını tuttu:

[Fact]
public void Sabit50_tam_esikte_250_TL_gecerlidir()
{
    // Kural: "ara toplam 250 TL ve üstündeyse geçerli".
    var sonuc = Hesapla(250m, "SABIT50");
    Assert.Equal(new SepetSonucu(250m, 0m, 50m, 49.90m, 249.90m, false), sonuc);
}

Expected: SepetSonucu { AraToplam = 250, KuponIndirimi = 50, Odenecek = 249,90, ... }
Actual:   SepetSonucu { AraToplam = 250, KuponIndirimi = 0,  Odenecek = 299,90, ... }

44 testten biri kırıldı ve kırılan test tam olarak hatayı gösteriyordu. Aynı model, aynı istem, aynı kod; tek fark, kuralın koddan ayrı bir yerde yazılı olması.

Neden böyle oluyor?

Test literatüründe bunun bir adı var: oracle problemi. Bir testin iki parçası vardır: girdiyi hazırlayan kısım ve "doğru sonuç şu olmalı" diyen kısım. İkinci kısım, yani oracle, beklenen davranışı bilmeyi gerektirir. Kodu okuyarak bulabileceğin şey ise kodun bugünkü davranışıdır.

AI'a yalnızca kodu verdiğinde, beklenen davranış için elindeki tek kaynak o kod. 24 Java projesi üzerinde yapılan bir çalışma da aynı sonuca varıyor: LLM ile üretilen testler çoğunlukla programın beklenen değil gerçek davranışını yakalıyor, bu da hata bulmayı zorlaştırıyor. Benim küçük deneyim bu bulgunun tek bir örneği.

Fatura hikâyesine dönünce bir ayrıntı daha var. Orada hata koddan değil kuralın kendisinden geliyordu: "A gelirse ödendi" kuralı da yanlıştı. Testleri o kuralla yazdırsaydım yine yeşil kalırlardı. Yani "kuralı ver" derken kastettiğim, kuralın asıl kaynağı: bankanın durum kodu tablosu, sözleşme, analiz dokümanı. Kodun başındaki yorum bile çoğu zaman kodu yazanın anladığıdır.

Eski kodu bilerek mühürlemek

Burada bir ayrım yapmak gerekiyor, çünkü "bugünkü davranışı kilitleyen test" her zaman kötü değil.

Eski bir koda dokunmadan önce, onun şu an ne yaptığını testlerle kilitlemek bilinen bir yöntem: characterization test. Amacı, refactor sırasında davranışın değişmediğinden emin olmak. Bu iş için AI gerçekten iyi; C varyantındaki testler refactor güvencesi olarak çok işe yarar.

Sorun, bu testlerin sonradan "kodun doğru olduğunun kanıtı" diye okunması. Altı ay sonra biri 250 TL'lik sepette kuponun çalışmadığını bildirdiğinde, ilk tepki kolayca "testi var, öyle olmalı" olabilir.

AI'a test yazdırırken

Bu ölçümden ve kendi yaşadığımdan çıkardıklarım:

Kuralı koddan ayrı ver. Yeni kodda zaten iş kuralıyla birlikte veriyorsun, sorun çıkmıyor. Eski kodda da kuralı ayrıca yaz ya da kaynağını ekle; yalnızca sınıfı verirsen test, kodun fotokopisi olur.
Kırılan testi hemen "düzelt" deme. D'de kırılan test, hatayı bulan testti. AI'a "testler kırıldı, düzelt" dersen büyük ihtimalle testi koda uydurur ve C'ye dönersin. Önce kodun mu testin mi yanlış olduğuna karar ver.
Eski koda yazdırılan testleri ne olduklarıyla adlandır. Bunlar characterization test. İsimde ya da açıklamada "mevcut davranış" dediğinde, okuyan kişi onları şartname sanmaz.
Mutation skorunu doğru oku. Yüksek skor, testlerin değişikliği fark ettiğini söyler. Testlerin doğru şeyi koruduğunu söylemez. Hatalı davranış da %100 skorla korunabiliyor.

Ölçmediğim şeyler

Bu deney küçük: 80 satırlık tek bir modül, tek bir model, her varyant için tek bir üretim. Başka araçları (Copilot, Cursor vb.) denemedim. Yan etkisi olan, veritabanına ya da dış servise bağlı büyük bir sınıfta AI'ın sınırları bu kadar iyi bulup bulmadığını da bilmiyorum; benim modülümdeki sınırlar kodda açık açık sabit olarak duruyordu. Gerçek kodda kural çoğu zaman üç sınıfa dağılmış durumda ve oraya baktığımda sonucun bu kadar temiz çıkacağını sanmıyorum.

Kesin söyleyebileceğim tek şey şu: kodu verdiğinde AI kodun ne yaptığını test eder; ne yapması gerektiğini test etmesini istiyorsan, bunu ona sen söylemelisin.

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

Feature flag teknik borca nasıl dönüşür?

Hüseyin Bozdemir — Fri, 23 Oct 2026 18:28:35 +0000

Bir tenant'ı mutlu etmek için açılmış bir flag'imiz vardı. Ürün o tenant'ta biraz farklı çalışsın diye veritabanındaki ayar tablosuna bir satır eklenmiş, kodda da o satıra bakan bir if yazılmıştı. Sonraki her geliştirmede o if'i bozmamak için kulağı tersten tuttuk. Yeni özellik o tenant'ta nasıl davranacak, eski yol hâlâ çalışıyor mu, testte o tenant'ın ayarını da açtık mı? Sonra bir gün öğrendik ki o tenant ürünü kullanmayı çoktan bırakmış.

Feature flag, kodu yeniden yayınlamadan bir davranışı açıp kapatan anahtardır. Bu yazının iddiası şu: tek bir müşteri için açılan flag'in bir sahibi ve bir bitiş tarihi olmaz; bu yüzden kapanmaz ve zamanla teknik borca dönüşür.

Feature flag nedir, neden kapanmaz?

En basit hali bir config değeri; bizde olduğu gibi veritabanında tenant bazlı bir ayar da olabilir: "bu tenant'ta yeni ekran açık, diğerlerinde kapalı."

Martin Fowler'ın feature toggle yazısı flag'leri ömürlerine göre ayırır. Bir özelliği yarım haliyle canlıya almak için açılan release toggle birkaç hafta yaşar ve özellik herkese açılınca silinir. Bir müşteriye ya da pakete özel davranışı açan permissioning toggle ise uzun ömürlüdür; aslında bir ürün kararıdır.

Sorun, tenant'a özel flag'in ikisinin arasında kalması. Geçici bir ihtiyaç için açılır ("şimdilik bu müşteride böyle olsun"), ama kalıcı bir ayar gibi saklanır. Kapatılacağı bir tarih yoktur, kapatma kararını verecek bir sahibi de yoktur. Ayar tablosunda bir satır olarak durur ve kimse onu silmeye cesaret edemez, çünkü kimin kullandığını bilen yoktur.

Bedeli kodda ödenir

Her flag kodda iki yol demek. İki flag dört kombinasyon, üç flag sekiz. Bunların hepsi test edilmez; genelde varsayılan yol test edilir, flag'li yol "eskiden çalışıyordu" diye kalır.

Asıl maliyet yeni geliştirmede ortaya çıkıyor. Bizdeki flag tek bir tenant içindi ama o tenant'ın yolu her yeni işin içine girdi. Tasarımı o yolu bozmayacak şekilde eğip büktük. Sonunda kodun bir kısmı, artık kimsenin kullanmadığı bir davranışı korumak için vardı.

Tenant'ın ürünü bıraktığını da sonradan öğrendik. O dalın en son ne zaman çalıştığını gösteren bir şey yoktu.

Temizlik

Bu olaydan sonra feature flag temizliği yaptık ve tenant'a özel davranışların hepsini ortak davranışa çektik: her tenant aynı yoldan geçiyor. Flag'li dallar koddan silinince, her yeni işte sorulan "o tenant'ta ne olur?" sorusu da ortadan kalktı.

Yeni bir flag açarken

Temizlik bir kez yapılınca bitmiyor; yeni flag'ler aynı yoldan gelir. Bir flag eklerken şu üç soruya cevap verilmiş olmalı:

Sahibi kim? Kapatma kararını verecek kişi ya da ekip. Sahibi olmayan flag sonsuza kadar yaşar.
Ne zaman silinecek? Geçici bir flag'in son kullanma tarihi olmalı. Fowler'ın yazısında anlatılan bir yöntem, tarihi geçen flag'de testi kırmak.
Kim kullanıyor? Flag'li yol çalıştığında bunu tenant bilgisiyle loglamak ya da saymak. Son 90 günde hiç çalışmamış bir dal, silinmek için en güçlü argümandır.

İkinci maddenin .NET'teki basit bir hali:

public sealed record FeatureFlag(string Ad, string Sahip, DateOnly SonKullanma);

public class FlagTarihleriTesti
{
    [Fact]
    public void Suresi_gecmis_flag_kalmasin()
    {
        var bugun = DateOnly.FromDateTime(DateTime.UtcNow);

        // FlagKatalogu: flag'lerin tutulduğu yer (ayar tablosu, config)
        var gecmis = FlagKatalogu.Tumu
            .Where(f => f.SonKullanma < bugun)
            .Select(f => $"{f.Ad} ({f.Sahip})");

        Assert.Empty(gecmis);
    }
}

Test kırıldığında iki seçenek var: flag'i silmek ya da tarihi bilerek uzatmak. İkisi de bir karar; önemli olan, flag'in kendiliğinden yaşamaya devam etmemesi.

Bizim hikâyemizde bu üç sorudan yalnızca üçüncüsü sorulmuş olsaydı, o tenant'ın gittiğini çok daha önce öğrenirdik.

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

Anthropic Scion nedir, git neden yetmedi?

Hüseyin Bozdemir — Fri, 23 Oct 2026 18:28:30 +0000

Anthropic Mayıs 2026'da günde ortalama 2.500 kod değişikliği birleştiriyordu. Eylül'de bu sayı 30.000'i geçti. Kodun çoğunu artık ajanlar yazıyor ve 13 Ekim'de yayımlanan mühendislik yazısına göre bu yükü git taşıyamadı. Scion, Anthropic'in kendi monorepo'su (şirketin bütün kodunun durduğu tek depo) için yazdığı ve git'in yerine geçirdiği şirket içi sürüm kontrol sistemi.

Scion'u yedi kişilik bir ekip yazdı, göç beş ayda bitti. Aynı dönemde kendi code review aracını (Antique), kod aramayı ve dizin bazında yetkilendirmeyi de baştan yazdılar.

Git'in hangi varsayımı bozuldu?

Git dağıtık bir sistem. Varsayılan bir git clone deponun yalnızca son halini değil, bütün geçmişini makineye indirir. Uçakta commit atabilmen, sunucu çökse de geçmişin her kopyada durması bu tasarımdan gelir. Varsayım şu: istemci çoğu zaman çevrimdışıdır ve elinde her şeyin tam bir kopyası olmalıdır.

Anthropic'in istemcileri ise neredeyse hiç çevrimdışı olmuyor. Ajanlar, CI işleri ve geliştirme ortamları hep ağa bağlı. Rakamlar yazıdan:

Ana dalın geçmişi tek başına 100 GB'a yakın, sıkıştırılmış bir çalışma kopyası 25 GB'ın üstünde.
CI için günde 25 milyon civarında checkout yapılıyor. Her birini düz git ile çekmek günde 600 PB'ın üstünde trafik demek.
Yükü dağıtmak için en yoğun dönemde birkaç yüz iç git aynası çalıştırmışlar.

Yani git'in çevrimdışı çalışma için ödettiği bedeli (her kopyada tam geçmiş) her gün milyonlarca kez ödüyorlar, karşılığında aldıkları şeyi ise hiç kullanmıyorlar.

Scion neyi farklı yapıyor?

Ağırlığı istemciden sunucuya taşıyor. Geçmiş, blame, commit, merge ve rebase sunucuda yapılıyor; istemci yalnızca kendi değişikliklerini ve sınırlı bir önbellek tutuyor. Bir CI işi tüm depoyu çekmek yerine yalnızca ihtiyaç duyduğu dosyaları istiyor, bazı yazma işleri hiç checkout yapmadan API üzerinden yürüyor.

Yazıda iki rakam öne çıkıyor: altyapı eski git aynası düzenine göre CPU ve bellekte 200 kat küçülmüş, CI checkout'ları dakikalardan saniyelere inmiş. İkisi de şirketin kendi ölçümü.

Git bitti mi?

Hayır, ve bunu ilk söyleyen Anthropic'in kendisi. Yazıda Scion'un genel kullanım için git'in yerini tutmayacağı açıkça yazıyor; sistem tek bir dev depo ve hep çevrimiçi istemciler için tasarlanmış. Açık kaynak yapma planları da yok. Onun yerine fikirlerin bir kısmını GitHub ve GitLab'le birlikte git dünyasına taşımak istiyorlar, örneğin sunucu tarafında Scion'dakine benzer kapsamlı RPC'ler.

Bu yol yeni de değil. Google yıllardır kendi monorepo'sunu Piper ile, Meta Sapling ile yönetiyor ve Anthropic de tekniklerin çoğunu bu iki projeden aldığını yazıyor. Farklı olan, bu kez ölçeği büyüten şeyin binlerce mühendis değil, ajanlar olması.

Benim yorumum: asıl yük review'da

Haberde beni en çok düşündüren kısım review oldu. AI'la geliştirmeyle birlikte review'lar çok zorlaştı; tek bir PR'da satırlarca değişiklik oluyor. Review için bile AI kullanılıyor, ama yine de insan kontrolü şart.

Anthropic'in yaşadığı da bence aynı yükün çok daha büyük ölçekteki hali: kod yazmak ucuzladıkça onu okumak, test etmek ve birleştirmek pahalılaşıyor. Onlar sürüm sistemine kadar inmek zorunda kalmış.

Git tarafında ise bizi henüz zorlayacak boyutta değil. Kendi yazdığımız bir sürüm kontrol sistemine geçmek de şu an için bana gerçekçi gelmiyor. Fintech şirketleri yeni çıkan bir şey tamamen oturmadan köklü bir değişiklik yapmaz; önce o sistemin denenmesini bekler.

Senin ekibin için de büyük ihtimalle değişen bir şey yok. Ama ajanların açtığı PR'ları kimin ve nasıl incelediği sorusu, git'in sınırlarından çok daha önce kapına gelecek.

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

REA nedir? Ajanla tersine mühendislik

Hüseyin Bozdemir — Fri, 23 Oct 2026 18:28:26 +0000

Ekim'de GitHub'da en hızlı yükselen depo bir yapay zekâ modeli ya da yeni bir framework değil, bir tersine mühendislik aracı oldu. REA (Reverse Engineer Anything) 23 Ekim itibarıyla 370 binin üzerinde yıldızı geçti; ay başında adını bilen yok gibiydi.

REA, Claude Code, Codex, Cursor ya da Gemini CLI gibi kodlama ajanlarına tersine mühendislik araçlarını tek bir MCP sunucusu üzerinden bağlayan, MIT lisanslı açık kaynak bir araç. Fikri basit: bir uygulamada beğendiğin bir özellik var, kaynak kodu elinde yok. Ajana "bu özellik nasıl çalışıyor, kanıtıyla göster" diyorsun, ajan da REA'nın araçlarıyla uygulamanın içine bakıyor.

REA ne yapıyor?

MCP (Model Context Protocol), bir ajanın dış araçları çağırmasını sağlayan ortak bir protokol. REA bu protokolle ajana bir dizi inceleme aracı sunuyor ve kurulumu tek komut: npx rea-agents setup. Komut, seçtiğin ajanlara REA'yı kaydediyor ve ajanın nasıl inceleme yapacağını anlatan talimatları ekliyor.

REA ile bir inceleme nasıl ilerler: Ajan, bir uygulamadaki özelliğin nasıl çalıştığını sorar. Soru MCP araç çağrısı olarak REA'ya gider. REA bilgisayardaki analiz araçlarını çalıştırır: Ghidra, Hopper ya da IDA ile derlenmiş programlar; JavaScript, Electron ve .NET için yerleşik statik analiz; tarayıcı, APK ve ağ kayıtları. Sonuç kanıtları ve bilinmeyenleriyle ajana döner; ajan açıklar, benzerini yazar ve test eder.

Asıl iş REA'nın kendisinde değil, arkasına bağladığı araçlarda. Derlenmiş programlar için bilgisayarında kurulu Ghidra, Hopper ya da IDA'yı kullanıyor; yani kendi decompiler'ı yok. JavaScript ve Electron uygulamalarını, .NET dosyalarını ise ek bir araç olmadan, programı çalıştırmadan okuyabiliyor. Bunların yanında web sitelerini bir tarayıcı üzerinden, Android uygulamalarını JADX ile, kaydedilmiş ağ trafiğini de HAR dosyalarından inceleyebiliyor.

REA, Hopper'ı kendisi başlatıp bir programı incelerken. Görsel: REA deposu (MIT lisansı).

Projenin README'si iki noktada dürüst. Analiz senin bilgisayarında çalışıyor, ama araçların bulduğu sonuçlar ajana, dolayısıyla ajanın kullandığı model sağlayıcısına gidiyor. Bir de REA her bulguyu kanıtıyla ve "bunu bilmiyorum" dediği yerlerle birlikte döndürüyor; uygulamanın orijinal kaynak kodunu geri getirdiğini iddia etmiyor.

Örneklerde ne var?

Projenin örnek vakaları neyin mümkün olduğunu iyi gösteriyor. Birinde Notion'ın masaüstü uygulamasında panoya kopyalama özelliği, ekrandan Electron'un iç katmanlarına kadar izleniyor. Diğerinde eski bir oyun olan DX-Ball'da topun sesinin hangi hoparlörden çıkacağını hesaplayan fonksiyon assembly'den C'ye geri yazılıyor; yeniden yazılan kod, orijinal programla 3.205 test durumunda aynı sonucu veriyor.

Örnek vakalar: DX-Ball, Notion ve TH04. Görsel: REA deposu (MIT lisansı).

Abartı mı?

Kısmen. Ajanları Ghidra'ya bağlamak yeni bir fikir değil; GhidraMCP Mart 2025'ten beri var. InfoQ'nun haberine göre Hacker News'te de ilk soru buydu: ajana "Ghidra'yı kur ve kullan" demekten farkı ne? Bazı kullanıcılar REA ile daha iyi sonuç aldığını söylüyor, ama bunu ölçen bağımsız bir karşılaştırma yok.

REA'nın asıl katkısı kolaylık gibi duruyor: tek kurulum, tek arayüz ve birçok dosya türü. Yıldız sayısı da bir ilgi göstergesi, kaç kişinin gerçekten kullandığını söylemiyor.

Nerede durmalı?

Tersine mühendislik meşru bir iş: güvenlik araştırması, zararlı yazılım analizi, eski bir sistemin nasıl çalıştığını anlamak, başka bir yazılımla uyumlu çalışacak bir şey yazmak. Ama sınırı ince ve REA'nın sorumlu kullanım metni bu yüzden açık konuşuyor: yalnızca sahibi olduğun ya da incelemeye yetkin olduğun yazılım; lisans kontrolünü, DRM'i ya da kimlik doğrulamayı atlatmak yok. Tersine mühendislik bazı ülkelerde ve bazı lisans sözleşmelerinde kısıtlı, sorumluluk da kullanıcıda. Hopper ve IDA gibi ticari araçların lisansını da ayrıca alman gerekiyor.

Bir de şirket ortamında unutulan bir nokta var: incelediğin dosya senin bilgisayarında kalsa bile, ondan çıkan kod parçaları ve bulgular model sağlayıcısına gidiyor. Bir iş ortağının verdiği kapalı bir kütüphaneyi ajana inceletmeden önce bunun sözleşmeye uyup uymadığına bakmak gerekiyor.

Özetle REA, kaynak kodu olmayan bir şeyi anlamaya çalışırken ajanına doğru araçları veriyor; neyi anlamaya yetkin olduğuna karar vermek yine sana kalıyor.

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

PHP2Shell nedir, açık nasıl çalışıyor?

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

PHP2Shell, PHP'nin kendisinde bulunan ve 21 Ekim 2026'da yamalanan iki kritik açığa (CVE-2026-109618 ve CVE-2026-109619) verilen ad. Aynı gün Hollanda hükümeti DigiD'yi (vatandaşların devlet hizmetlerine girdiği kimlik sistemi) ve MijnOverheid'ı kendi isteğiyle kapattı. Meclisin ve ulusal siber güvenlik merkezi NCSC'nin siteleri de kapandı. Ortada bilinen bir saldırı yoktu; sebep, aynı gün yamalanacak iki PHP açığıydı.

İki açık da üzerine yazılan uygulamada değil, dilin çalışma zamanında. İkisi de CVSS 4.0'da 9,2 puan aldı ve bazı kurulumlarda giriş yapmamış birinin tek bir HTTP isteğiyle sunucuda kod çalıştırmasına izin veriyor. Düzeltilmiş sürümler (8.5.12, 8.4.27, 8.3.36 ve 8.2.35) 21 Ekim 14:00 UTC'de çıktı.

Duyuru aslında 22 Ekim'e planlanmıştı. Huntress'in aktardığına göre 20 Ekim sabahı açıkların varlığı Hacker News'teki bir gönderiyle sızınca PHP ekibi sürümü bir gün öne çekti. Türkiye'de Siber Güvenlik Başkanlığı da 21 Ekim'de TR-26-1372 kodlu bildirimle ulusal çapta tarama başlattı.

Sonraki saatlerde liste uzadı. Fransa, Danimarka ve Finlandiya'da devlet siteleri geçici olarak kapandı, Kanada da bazı federal sitelerini kapattı. Japonya'da ANA, JR West ve MUFG bankası bazı sayfalarını ya da hizmetlerini durdurdu; Wikimedia da bazı sistemlerini önlem olarak kapattı.

Açığı yapay zekâ mı buldu?

Kısmen. Açıkları Wiz'in araştırma ekibi buldu; yazıda PHP ekibine, Calif'e ve OpenAI'a keşif, koordinasyon ve yamanın doğrulanmasındaki katkıları için teşekkür ediliyor. Wiz çalışma boyunca kendi aracı Wiz Atlas'ı, Gemini 4 Argon'u ve GPT-5.6 Sol'u kullandığını, Gemini'nin açığın bulunmasına büyük katkı verdiğini yazıyor. Modeller exploit'i farklı PHP sürümlerine, ayarlara ve bellek düzenlerine uyarlamakta da kullanılmış.

Zaman çizelgesi de dikkat çekici. İlk açık 19 Ağustos'ta bulunmuş, iki gün içinde Drupal ve WordPress'te giriş gerektirmeyen kod çalıştırma doğrulanmış ve 24 Ağustos'ta PHP ekibine bildirilmiş. Wiz'e göre açıklı kod on yıldan uzun süredir PHP'deydi ve 5.4'e kadar geriye giden sürümler etkileniyor.

Wiz'in altını çizdiği nokta da bu: böyle bir hatayı çalışan bir saldırıya dönüştürmek eskiden çok emek isteyen bir işti ve modeller bu engeli ciddi biçimde düşürdü.

Açık nasıl çalışıyor?

PHP'nin klasik modelinde her istek sıfırdan başlar: betik çalışır, cevap döner, isteğe ait her şey silinir. Ama istekleri karşılayan süreç silinmez. PHP-FPM'de ya da Apache mod_php'de aynı işçi süreç (worker) yüzlerce isteği art arda işler ve her isteğin sonunda belleği temizleyip bir sonrakine hazırlanır. İki açık da bu temizliğin varsayımlarını bozuyor.

CVE-2026-109619'da isteğe ait bir iç durum, gösterdiği bellek serbest bırakıldıktan sonra da yerinde kalıyor. Aynı işçinin aldığı bir sonraki istek, bu durum sıfırlanmadan önce onu kullanabiliyor. Bu klasik bir use-after-free: artık başka bir şeye ait olabilecek bir bellek bölgesine eski bir adresle dokunmak. Saldırgan o bölgeyi kendi isteğiyle doldurabilirse okunan veri de, çalışan kod da onun olur.

CVE-2026-109618'de PHP, istek verisini hazırlarken bellek sınırına takılıp yarıda kesiliyor. İsteğin sonundaki temizlik, yarım kalmış bu veriyi geçerli sanıp üzerinde işlem yapıyor.

Asıl ürkütücü kısım şu: php.net'in duyurusuna göre mod_php'de gösterilen istismar, uygulama kodu hiç çalışmadan tetikleniyor. WordPress'i, eklentileri ya da framework'ü güncellemek bir şey değiştirmiyor; kodunun ne kadar temiz olduğu da. Açık, kodunu çalıştıran şeyin içinde. Önerilen geçici ayarların (post_max_size, session.upload_progress) hepsinin isteğin gövdesi okunurken devreye girmesi de bunu destekliyor.

Ne yapmalı?

Tek gerçek çözüm güncellemek. PHP'nin sürüm notları tam bir geçici çözüm olmadığını açıkça söylüyor. Önerilen ayarlar (memory_limit, post_max_size, session.upload_progress.enabled = 0) yalnızca bazı saldırı yollarını daraltıyor ve uygulamanın ezemeyeceği yerde, örneğin php_admin_value ile verilmeleri gerekiyor.

8.2 ile 8.5 arasındaysan yukarıdaki sürümlere geç. 8.2'nin desteği 31 Aralık 2026'da bitiyor.
8.1 ve öncesi PHP ekibinden güncelleme almıyor. 7.4, 8.0 ve 8.1 için yalnızca küçük kaynak yamaları yayımlandı; dağıtımının ya da hosting firmanın bunları uygulayıp uygulamadığına bak.
Sürümü kontrol ederken php -v'ye güvenme. Komut satırındaki PHP ile web sunucusunun kullandığı PHP-FPM ya da mod_php farklı kurulumlar olabilir; php-fpm -v ya da geçici bir phpinfo() sayfası (işin bitince sil) gerçek sürümü gösterir.
Güncellemeden önce saldırıya uğramış olabilirsin. Huntress'in önerisi, php-fpm ya da httpd sürecinin altından sh, bash, curl, wget gibi süreçlerin başladığı anlara bakmak; web klasöründe yeni dosya, yeni cron işi ve yeni kullanıcı aramak.

Siten paylaşımlı hosting'deyse PHP'yi sen değil firma günceller. Panelden sürümü kontrol etmek yine senin işin.

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