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.
Şö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) Daha fazla bilgi için
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.
3 comments