Azure DocumentDB ile Bankalarda Customer 360: Dağınık Veriden Net Resme
Bankada müşteri resmî neden hâlâ yamalı bohça?
Bakın şimdi, bankacılıkta ana mesele çoğu zaman ürün değil, müşteriyle kurulan bag oluyor. Ama işin garibi su: o bag tek bir yerde durmuyor. Mobil uygulamada ayrı bir iz, çağrı merkezinde başka bir kayıt, subede bambaşka bir not… Sonra biri kredi başvurusu yapıyor, diğeri kart itirazi açıyor, öbürü de chatbot’ta “hesabim neden bloke öldü?” diye soruyor. Müşterinin hikâyesi ortada var ama parçalar hep dağınık.
Bu tabloyu ben ilk kez 2018’de İstanbul’da bir özel bankanın dönüşüm projesinde net gördüm. CRM tarafı ayrı konuşuyor, core banking ayrı konuşuyor, risk ekibi işe Excel dosyalarıyla dolasiyordu. Açık konuşayım, dışarıdan bakınca sistemler çalışıyor gibi görünüyordu; icerideyse herkes aynı müşteriye farklı işim veriyordu resmen. Hani klasik “tek doğruluk kaynağı” lafı vardır ya… işte tam orada sinifta kalınıyor.
Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.
Işin aslı şu ki Customer 360 sadece raporlama kolaylığı değil. Operasyonel hız veriyor, çapraz satış için zemin hazırlıyor, sahteciliği daha erken yakalatıyor ve denetim gunlerinde epey nefes aldırıyor. Bunu kucumseyen çok olur ama büyük kurumlarda küçük bir gecikme bile zincirleme etki yaratabiliyor.
Bir de şu var: Türkiye’de bankalar veri konusuna baya temkinli yaklasir. Bu kötü değil; hatta iyi bile sayılır çünkü regülasyon baskısı gerçek. Gel gelelim bu temkin bazen yeniliği yavaşlatıyor. O yüzden modern bir Customer 360 yaklaşımı kurarken “her şeyi tek yere taşıyalım” kafası yerine “doğru veriyi doğru hızda erişilebilir kilalim” demek daha mantıklı geliyor bana (şaşırtıcı ama gerçek)
Azure DocumentDB burada neyi değiştiriyor?
Peki neden? Azure DocumentDB’nın MongoDB uyumluluğu sayesinde ekipler yeni bir dünyaya sıfırdan alışmak zorunda kalmıyor. BSON dokümanlar, aggregation pipeline’lar, koleksiyon mantığı… Bunlar zaten birçok ekibin bildiği şeyler (ki bu çoğu kişinin gözünden kaçıyor). Yanı öğrenme egirisi fena değil, hatta bayağı iş görüyor. Özellikle mevcut Mongo alışkanlığı olan kurumlarda geçiş bariyerini ciddi şekilde düşürüyor.
Çok konuştum, örnekle göstereyim.
Ben bunu 2023’te Ankara’daki bir fintech müşterisinde test ederken fark ettim. Ekiple konustugumuzda en büyük korku performanstan çok operasyondaki karmasiklikti. Çünkü yeni platform demek yeni bakım prosedürü demek, yeni yetki modeli demek, bazen de gece yarısı telefon demek… Azure tarafında yönetilen servis rahatlığı olunca bu yükün önemli kısmı omuzlardan kalkıyor. Bu konuyla ilgili azure konusundaki yazımız yazımıza da göz atmanızı tavsiye ederim.
Yanı, Ama dürüst olayım: her şey güllük gülistanlık değil. Mongo uyumluluğu güçlü olsa da bazı ileri seviye uygulamalarda davranış farkları çıkabiliyor; özellikle sorgu desenleri ve indeks stratejileri konusunda körlemesine geçiş yapmak iyi fikir değil. Ilk denememde ben de ufak bir hata aldım — yanlış indeks yüzünden pipeline beklediğimden yavaş çalıştı. Çözümü basitti: önce veri modelini toparladik, sonra okuma yollarını yeniden tasarladik.
| Konu | Klasik Dağınık Yapı | Customer 360 + Azure DocumentDB |
|---|---|---|
| Müşteri görünümü | Bölük pörçük | Tek noktadan erişim |
| Sorgu hızı | Sistemler arası gidip gelme | Daha az kopya veriyle hızlı sorgu |
| Operasyon yükü | Yüksek | Daha kontrollü |
Tuhaf ama, (Tabloyu bozmamak için kısa keseyim: pratikte kazanç en çok operasyon ve görünürlük tarafında hissediliyor.) Visual Studio 2026 Insiders 3’te TypeScript 7 Beta Varsayılan yazımızda bu konuya da değinmiştik. Bu konuyla ilgili Kubernetes v1.36 Controller Staleness: Bayat Cache Sorunu Bitti mi? yazımıza da göz atmanızı tavsiye ederim.
Müşteri 360 nasıl kurulmalı? Önce modeli düzeltin
E tabi teknoloji kısmına atlamak kolay — Önce veri modelini konuşmak lazım. Müşteriyi kişi mi sayacaksiniz,
hane mi sayacaksiniz,
ürün ilişkilerini nasıl tutacaksınız? Bu sorular netleşmeden hiçbir platform sizi kurtarmaz. Ben genelde projelerde ilk toplantiyi teknolojiyle değil,
müşteri tanimiyle baslatiyorum. Çünkü yanlış tanımlanan müşteri nesnesi,
sonradan bütün raporu zehirliyor.
İtiraf edeyim, $graphLookup gibi mekanizmalar burada ilginçleşiyor.
Mesela aile üyeliği olan hesaplar,
ortak cihaz kullanan müşteriler,
aynı adres üzerinden açılmış kartlar…
Bunları gormezseniz risk analizi eksik kalır.
Bir banka projesinde bunu canlıya almadan önce
gösterge panosunda birkaç bağlantıyı elle cizmistik;
daha sonra otomatik grafik sorguları ile
aynı oruntunun saniyeler içinde bulunduğunu görmek açıkçası sevindiriciydi.
Hani insan bazen “bu kadar mıydı?” diyor ya…
Müşteri 360’in asıl değeri tekil kayıt toplamakta değil; ilişkiyi görünür kilmakta yatıyor.
Aynı kisiyi beş sistemde görmek kolaydır.
Zor olan, o kişinin davranışını bağlamıyla birlikte okumaktir.
Küçük ekip mi büyük kurum mu? Aynı reçete işlemez
Size bir şey söyleyeyim, Küçük bir startup iseniz işiniz nispeten kolay olabilir; çünkü kaynak az olduğu için karar hızlı alinır. Tek takım olur, tek backlog olur ve veri modeli üzerinde tartışırken herkes aynı masada oturur (bazen fazla samimi bile olunur). Böyle yapılarda Mongo uyumlu bir yönetilen servis size hız kazandırır.
- Küçük ekip: Hızlı kurulum, basit şema evrimi, az sayıda entegrasyon.
- Büyük enterprise: Yetki ayrımı, audit izi ve veri yönetişimi on planda.
- Bütçe hassasiyeti: Başlangıçta hafif kapasiteyle ilerleyip kullanım arttıkça ölçeklemek daha mantıklı olabilir.
Bakın, Büyük kurumsal yapılarda işe oyun değişiyor.
Burada sadece teknik doğruluk yetmiyor;
uyum süreçleri,
rol tabanlı erişimler,
veri saklama politikaları
ve hatta departmanlar arası siyaset devreye giriyor…
2019’da İzmir’de bir sigorta grubunda yaşadığımız şey tam buydu:
Veri mimarisi güzel görünüyordu. Hukuk ekibi onay vermeden hiçbir alan canlıya çıkmadı.
Haklıydılar da aslında.
Finans sektöründe acele edilen mimarı sonradan pahalıya patlıyor.
Nerede iyi işler çıkarır? Nerede tökezler?
Yanı, Agragation Pipeline ile zenginlestirme yapmak gerçekten kullanışlı.
Segmentasyon tarafında yaş grubu,
ürün sahipliği,
davranış skoru veya bölgesel yoğunluk gibi kriterleri karistirip anlamlı kümeler çıkarabiliyorsunuz.
Bu yapı pazarlama ekiplerine ciddi hız verir;
risk ekipleri içinse anomali tespiti daha okunur hâle gelir.
Ama hayal kırıklığı yaşamamak için beklentiyi doğru koymak şarttır:
Bu platform sihirli değnek değil!
Veriniz kirliyse sonuç da kirlenir.
Eksik KVKK etiketleri varsa ekran parlıyor diye güvenmeyin;
temizlik işi yine sizin omzunuzda.
Ha bu arada maliyet meselesini de es geçmeyelim.
İşte, azure tarafında yönetilen hizmet kullanmanın bedeli var elbette;
TL bazında düşündüğünüzde özellikle döviz dalgalanmalarinda bütçe planlaması dikkat istiyor.
Fakat toplam sahip olma maliyetine baktığınızda
donanım yenileme,
yedeklilik kurma,
patch takibi
ve operasyon nobeti gibi kalemler azalınca tablo değişebiliyor.
Kaba hesapla ucuz görünen şey bazen pahalıya gelir; tersine de olabilir.
Aslında — durun biraz geri geleyim — mesele “hangi servis daha ucuz” sorusu değil yalnızca; hangi servisin size daha az sürpriz çıkardığı sorusu daha kritik.
{
"customerId": "C12345",
"signals": [
{"source": "mobile", "event": "login_failed"},
{"source": "callcenter", "event": "complaint_opened"},
{"source": "card", "event": "chargeback_request"}
],
"riskScore": 82
}Sahada işe yarayan birkaç pratik ipucu
Lafı gevelemeden söyleyeyim:
Ilk adım olarak kapsamınızı daraltın.
Her şeyi aynı anda dönüştürmeye çalışırsanız proje şişer. Yorulur.
Ben olsam önce üç akışı seçerim:
müşteri profili birleşimi,
olay akışı zenginleştirme
ve temel segmentasyon.
Bir de indeks tasarımını erkenden yapın;
sonradan eklenen indeks çoğu zaman yara bandına benziyor,
tam çözüm olmuyor.
Hele bir de deneme ortamında üretime benzeyen veri dağılımı oluşturmak önemli.
Kendi tecrübemde en sık gördüğüm hata şu:
geliştirmede harika çalışan sorgu canlıda çöküyor çünkü veri hacmi gerçeğe uymuyor…
2024 Nisan’ında bir kamu bankasında buna benzer sorun yaşamıştık;
sorun servis değildi,
test datasının fazla steril olmasıydı!
Ne yazık ki bu detay gözden kaçınca insan boş yere platform suçluyor.
Eğer bütçeniz sınırlıysa alternatif olarak her senaryoda tam kapsamlı Customer 360 kurmaya çalışmayın; önce olay odaklı mini-360 yaklaşımını deneyebilirsiniz. Mesela yalnızca kredi başvurusu yapan müşteriler için birleşik görünüm oluşturup başarıyı ölçmek oldukça makul bir başlangıç oluyor. Kubernetes v1.36 Memory QoS: Katmanlı Bellek Koruması Geldi yazımızda bu konuya da değinmiştik. Bu konuyla ilgili Azure Developer CLI Nisan 2026: Çok Dilli Hook Devri Başladı yazımıza da göz atmanızı tavsiye ederim.
Sıkça Sorulan Sorular
Azure DocumentDB ile MongoDB arasındaki temel fark ne?
Aslında en büyük fark yönetim modeli ve Azure entegrasyonu. Yanı MongoDB uyumluluğu sayesinde tanıdık araçlarla çalışmaya devam ediyorsunuz,. Altyapıyı yönetme işi bulut tarafında çok daha kontrollü ilerlyor.
Customer 360 bankalar için neden bu kadar önemli?
Açıkçası, Şöyle düşünün: müşteri bilgisi farklı sistemlere dağıldığında hem hizmet kalitesi düşüyor hem de risk analizi zayıflıyor. Tek bir resim olduğunda işe ekipler çok daha hızlı karar verebiliyor. Bence bu, bankacılıkta gerçekten kritik bir nokta.
Küçük ekipler de bu yapıyı kullanabilir mi?
Kesinlikle, hatta tecrübeme göre çoğu zaman daha rahat kullanıyorlar. Az entegrasyon varsa başlangıç çok daha hızlı oluyor.
Maliyet konusunda neye dikkat etmek lazım?
Açıkçası en önemli şey pilot aşamada düşük kapasiteyle başlayıp gerçek kullanım verisine göre ölçeklemek. Yoksa gereksiz kaynak tüketimi kaçınılmaz oluyor, hani boşa para gidiyor yanı.
Kaynaklar ve İleri Okuma
Azure Cosmos DB for MongoDB Resmî Dokümantasyonu
Azure Cosmos DB Vector Search Belgeleri
Microsoft Azure Cosmos DB Bloğu
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.
4 comments