Azure Cosmos DB’de Silinenleri Görmek: Change Feed’in Sessiz Gücü
Bir değişiklik, bazen bir olaydan fazlasıdır
Geçen sene Mart 2025’te, İstanbul’da bir perakende müşterisinde tuhaf bir şeyle uğraştık. Siparişler akıyordu, sorun yoktu;. Stok tarafında garip bir kayma vardı, ürün silinmiş gibi görünüyordu, buna rağmen arkadaki senkronizasyon katmanı hiçbir şey olmamış gibi davranıyordu. İşin aslı şu: klasik change feed ile çalışıyorsanız bazı şeyler gözünüzün önünden sessizce kayıp gidiyor. Silme de onlardan biri.
Azure Cosmos DB’nın all versions and deletes modu tam burada devreye giriyor. Ben bu duyuruyu ilk gördüğümde aklıma direkt audit log, compliance ve veri senkronizasyonu geldi, çünkü kurumsal tarafta mesele sadece “veri güncellendi mi?” değil; “ne zaman değişti, nasıl değişti, arada ne öldü, silindi mi?” soruları da aynı masaya oturuyor.
Bakın şimdi, modern uygulamalar veri yazıp kenara çekilmiyor. Bir kayıt güncelleniyor, başka sistem tetikleniyor; kayıt siliniyor, temizlik işi başlıyor; TTL doluyor, arkada bambaşka bir zincir hareket ediyor. O yüzden change feed’in olayı sadece hız değil… olayların tamamını görebilmek.
Küçük bir detay: Benim AZ-305 ve AZ-104 hazırlık sürecimde de hep aynı yere takılırdım: mimarı kararlar çoğu zaman teknik özellikten çok iş etkisiyle ilgili oluyor. Cosmos DB’deki bu yeni mod da öyle. Kağıt üstünde küçük dürüyor ama pratikte baya iş görüyor.
Latest version yetmiyorsa, neden yetmiyor?
Klasik change feed mantığı basit: son durumu veriyor. Hızlıdır, temizdir, çoğu senaryoda iş görür. Ama işin içine intermediate update’ler girince tablo biraz bozuluyor. Diyelim ki bir doküman üç kez güncellendi ve sız o sırada okumadınız; latest version modunda sadece son hali görürsünüz (yanlış duymadınız). Aradaki iki adım? Yok.
Bunu 2024 sonunda Ankara’daki bir finans projesinde net yaşadık. Müşteri hesap verisini başka bir analitik sisteme taşıyorduk ve ekip başlangıçta “nasıl olsa son hâl yeter” diyordu. Sonra denetim ekibi gelip “bu tutar nereden geldi?” diye sorunca anlaşıldı ki ara değişiklikleri kaybetmek küçük bir eksik değilmiş; resmen kör nokta yaratıyormuş.
Delete tarafı da ayrı dert. Soft delete kullanırsınız, isDeleted alanı koyarsınız, sonra bunun bakımını yaparsınız… sonra biri unutur ve işler karışır. All versions and deletes modu burada daha net çizgi çekiyor: silmeyi gerçekten silme olarak görüyor ve bunu akışın içinde size söylüyor.
Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.
Neleri gösteriyor?
Create ve update olaylarında yalnızca dokümanın son hâli yok; operasyon tipi de geliyor. Delete olduğunda işe item’ın id, partition key bilgisi ve silmenin TTL mi yoksa açıkça yapılan bir delete mi olduğu görülebiliyor (ben de ilk duyduğumda şaşırmıştım) — itiraf edeyim, beklentimin üstündeydi —. Bu ayrıntı kulağa kuru gelebilir ama büyük sistemlerde altın değerinde oluyor.
Açık konuşayım: bu özellik her proje için şart değil. Küçük bir startup iseniz ve üç mikroservisle ayakta duruyorsanız belki gereksiz karmaşa çıkarır. Ama enterprise yapıda audit baskısı varsa ya da downstream sistemleriniz çoksa, işin rengi tamamen değişiyor.
Cosmos DB change feed’in bu yeni modu bana göre “gösterişli” bir özellik değil; doğrudan operasyonel riski azaltan bir araç.
Aynı hesabın içinde iki farklı dünya kurulabilir
En sevdiğim taraflardan biri bu öldü desem yeridir. Her şeyi tek moda zorlamıyorsunuz. Hesap seviyesinde capability açılıyor. Kod tarafında hangi processor ya da trigger’ın hangi modu kullanacağını sız seçiyorsunuz. Yanı aynı container üzerinde hem latest version hem all versions and deletes çalıştırmak mümkün (tabiî lease container’ları ayrı tutarak).
Bunu geçen yıl Ege bölgesindeki bir lojistik firmasına anlatırken şöyle örnekledim: biri depo raflarını sayıyor gibi düşünün, diğeri işe kamyonun kapısından giren çıkan her koliyi not alıyor gibi… İkisinin ihtiyacı aynı değil ki zaten.
| Kullanım Alanı | Latest Version Mode | All Versions and Deletes Mode |
|---|---|---|
| Senkronizasyon | Yeterli olabilir | Daha güvenli ama daha detaylı |
| Audit / Compliance | Zayıf kalır | Bayağı uygun |
| Tekil güncel durum okuma | İyi iş görür | Bazen gereksiz ayrıntı verir |
| Delete sonrası işlem | Zorlaşır | Düzgün çözülür |
| Event sourcing benzeri yapı | Eksik kalır | Daha anlamlı olur |
Neyse uzatmayayım; eğer sadece “son durum” istiyorsanız eski model hâlâ yeterli olabilir. Ama işin içinde doğrulama, geri izleme ve zincirleme aksiyonlar varsa yeni mod ciddi rahatlık sağlıyor (buna dikkat edin)
Bence en güçlü kullanım alanları burada başlıyor
Audit ve compliance için sessiz kahraman
Kurumlarda denetim deyince herkesin yüzü biraz düşer ya (inanın bana). sebebi belli: eksik kayıt affedilmiyor. Bir bakıma, all versions and deletes mode burada komple geçmişi verdiği için güzel çalışıyor. Sadece belgeyi değil, belgenin yolculuğunu da görüyorsunuz.
Bunu biraz açayım.
Şöyle söyleyeyim, Bunun Türkiye’deki karşılığı özellikle bankacılık, sigorta ve kamu tarafında daha net hissediliyor. Kurumsal müşterilerimde gördüğüm kadarıyla bizde veri saklama kültürü genelde “bir yerde dursun yeter” seviyesinden çıkıp “hangi işlem ne zaman öldü” seviyesine geçince gerçek ihtiyaç ortaya çıkıyor (evet, doğru duydunuz)
Senkronizasyon var ama soft delete istemiyorum diyorsanız…
Soft delete çoğu ekipte ilk refleks oluyor. Sonra raporlar şişiyor, sorgular uzuyor, flag unutuluyor… hani insan eli değince hata kaçınılmaz oluyor ya, aynen öyle (ciddiyim). Delete event’ını doğrudan yakalayınca ikinci sınıf çözümlere bağımlılık azalıyor.
Açıkçası, Geçen ay Nisan 2026’da Gebze’de konuştuğum bir üretim firmasının ekibi tam bunu istiyordu: ERP’den gelen ürün verisini arama motoruna taşıyorlardı ama silinen ürünlerin indekslerden temizlenmesi gecikiyordu. Yeni modla birlikte temizlik daha deterministik hâle gelir diye düşündüm — bence doğru yönde atılmış adım.
Peki neden?
Tetiklenen iş akışları için fena değilmiş gerçekten)
Kayıt silindiğinde cache temizle, bildirım gönder, ilişkili veriyi kaldır… Bunların hepsi gayet doğal akışlar aslında ama eski modelde ekstra kontrol yazmanız gerekiyordu demeyeyim de bayağı uğraşıyordunuz diyeyim.
Kod tarafında nasıl düşünmeli?
İtiraf edeyim, Açık konuşayım, Functions" data-glossary-term="Azure Functions">Azure Functions trigger desteği gelmesi benim hoşuma gitti çünkü entegrasyonu sadeleştiriyor… fakat burada dikkat edilmesi gereken nokta şu: her şey fonksiyonla çözülmeye çalışılmamalı! Büyük hacimli akışlarda processor yaklaşımı hâlâ daha kontrollü olabilir.
// Psödokod mantığı
// Latest version consumer:
ProcessChanges(mode = "latestVersion");
// Audit consumer:
ProcessChanges(mode = "allVersionsAndDeletes");
// Aynı container üzerinde farklı lease container kullanımı
ConfigureLeaseContainer("orders-latest-leases");
ConfigureLeaseContainer("orders-audit-leases");Bu yapıyı ilk denediğimde küçük bir hata aldım; lease container isimlerini yanlış eşlediğim için processor sürekli yeniden başlıyordu. Hata mesajı çok süslü değildi açıkçası — klasik “why are you doing this to me?” tarzındaydı — çözüm işe basitti: lease izolasyonunu doğru kurmak gerekiyor.
Durun, bir saniye.
E tabi performans konusu da var. Her şeyi kaydedeyim derken maliyet yükselir mi? Yükselir tabiî ki… ama asıl soru şu: kaybettiğiniz görünürlük size daha pahalıya patlıyor mu? Bir finans kuruluşunda yanlış audit izinin yarattığı operasyon yükü bazen depolama maliyetinden çok daha can yakıcı oluyor.
Maliyet ve benim sahadan gördüğüm gerçekler
Bütçe tarafından bakınca mesele sadece Cosmos DB RU/s değil; change feed tüketicisinin altyapısı da devreye giriyor. Fonksiyonlar mı koşacak, container app mi kullanılacak, telemetry nereye gidecek… bunların hepsi toplam faturaya ekleniyor.. Türkiye’de TL bazında düşündüğünüzde kur dalgalanması da cabası oluyor; dün idare eden maliyet bugün biraz can sıkabiliyor.
Küçük ekipler için önerim net: önce latest version ile başlayın, gerçekten delete visibility ihtiyacınız varsa all versions and deletes’e geçin.
Büyük kurumsal yapılarda işe baştan iki ayrı kullanım modeli tasarlamak daha mantıklı olur çünkü sonradan refactor etmek bazen yeni geliştirmeden pahalıya geliyor.
Ha bu arada…
Cosmos DB’nın güzelliği burada: kapasiteyi değil davranışı seçiyorsunuz.
Ama davranışı seçerken operasyon yükünü de dürüstçe tartmak lazım.
Hayal kırıklığı dediğim nokta şu öldü:
bazı ekipler bu özelliği görünce pek çok problem çözüldü sanıyor.
Yok öyle yağma.
Veri modeli kötü işe change feed mucize yaratmaz.”
Bence ilk adımda şunları yapın
- Konteynerinizde hangi olayların gerçekten önemli olduğunu listeleyin.
- Create / update / delete ayrımına ihtiyacınız olup olmadığını test edin.
- Aynı anda iki consumer çalıştıracaksanız lease stratejisini planlayın. — ciddi fark yaratıyor
- Maliyet tarafını hem Azure faturası hem operasyon yükü olarak değerlendirin.
Zaten Azure Functions kullanan ekiplerde iş biraz daha rahat ilerleyebilir çünkü tetikleme modeli sadeleşiyor.Ben Logosoft’ta birkaç projede gördüm,fonksiyonlarla hızlı kazanım elde ediliyor. Uzun vadede gözlemleme olmadan yürümüyor.Application Insights olmadan böyle akışa girmek bana biraz karanlıkta araba sürmek gibi geliyor doğrusu.
Hani, Eğer mevcut içeriğe bakmak isterseniz şu yazılar da yakın dürüyor:Azure Functions İçin Yapay Zekâ Çalışma Alanı: Azure Functions İçin Yapay Zekâ Çalışma Alanı:
Buna ek olarak DevOps bakışını sevenler için Azure DevOps ve GitHub: Yapay Zekâ Çağında Nereye Gidiyor? yazısı da iyi gider; çünkü event-driven mimaride teslimat kadar gözlem de önemli oluyor,hani sırf deploy etmek yetmiyor ya,işte tam o taraf.
Sıkça Sorulan Sorular
Cosmos DB change feed ne işe yarıyor?
Change feed, hani container içindeki veri değişikliklerini sırayla akışa veren bir yapı. Yeni kayıtlar, güncellemeler ve bazı senaryolarda silmeler buradan okunuyor. Aslında modern entegrasyonlarda çok işe yarayan bir özellik.
All versions and deletes ile latest version arasındaki fark ne?
Aslında, Latest version sadece son hâli gösteriyor. Bir bakıma, all versions and deletes işe ara güncellemeleri ve silmeleri de veriyor. Yanı denetim veya olay geçmişine ihtiyacın varsa ikinci seçenek çok daha anlamlı, bence çoğu kurumsal projede bu tercih daha mantıklı.
Aynı container için iki modu birlikte kullanabilir mıyım?
Evet, kullanabilirsin. Capability hesabında açılıyor, mod seçimi işe tüketici tarafında yapılıyor. Dikkat etmen gereken tek şey, farklı lease container kullanman gerekiyor.
Tamamen soft delete yerine bunu kullanmalı mıyım?
Neredeyse her zaman değil açıkçası. Uygulamanın iş kuralına çok bağlı. Mesela soft delete bazı raporlama senaryolarında hâlâ pratik olabiliyor, ama delete event’i doğrudan almak çoğu kurumsal yapıda daha temiz dürüyor.
Kaynaklar ve İleri Okuma
Orijinal Microsoft Azure Cosmos DB blog duyurusu
Azure Cosmos DB Change Feed Resmî Dokümantasyonu
Change Feed Modları hakkında Microsoft Learn
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
Yorum gönder