EWS Bildirimlerinden Microsoft Graph’a Geçiş: Sessiz Ama Büyük Değişim
Biraz sert söyleyeceğim: EWS tarafında yıllardır çalışan bildirım mantığı iş görüyordu,. Artık eski dünyanın kokusu üstünde kalıyor. Hani hâlâ çalışıyor, evet; fakat ölçek, güvenlik ve operasyon yükü bir yerden sonra sizi yoruyor. Microsoft Graph’ın getirdiği model işe daha sade, daha modern ve açık konuşayım, bulut çağının temposuna daha yakın.
Bu dönüşümü ilk kez 2023 sonbaharında, İstanbul’da finans sektöründen bir müşteride masaya yatırdım. Ekipte klasik bir Exchange entegrasyonu vardı; push notification ile idare ediyorlar, bazı hayatı senaryolarda da polling’e dönüyorlardı. İşin aslı şu ki sistem “çalışıyordu”, ama çalışma hâliyle üretimde huzur aynı şey değil. Bu ne anlama geliyor? Her yeni mailbox artışı biraz daha bağlantı karmaşası, biraz daha hata ayıklama demekti.
Bunu biraz açayım.
Dürüst olmak gerekirse, Graph tarafına geçişte en büyük fark bence şu: tek bir bildirım modeli var gibi görünse de arka planda düşünme biçimi değişiyor. Artık uzun yaşayan oturumları kovalamıyorsunuz, event geldiğinde webhook alıp kenara çekilmiyorsunuz; change notification ile birlikte delta query’yi de masaya koyup resmî tamamlıyorsunuz. Bu bana hep depo kapısına gelen kargoyu not edip sonra içeride sayım yapmak gibi geliyor. Sadece zil çalınca yetmiyor yanı.
EWS’den Gelen Alışkanlıklar Neden Yetmiyor?
EWS notification framework üç farklı karaktere sahipti: push, pull ve streaming. Bunların her biri ayrı dert getiriyordu. Push tarafında public endpoint yönetimi vardı; pull tarafında sürekli sorgu yükü oluşuyordu; streaming işe uzun ömürlü bağlantılarla server ve client arasında ince bir ip üzerinde yürüyordu. Kağıt üstünde hepsi mantıklıydı ama pratikte operasyon ekibi için “bir tane daha servis açsak mı?” sorusunu sıklaştırıyordu (bu konuda ikircikliyim)
2019’da Ankara’da bir hosting altyapısında benzer bir yapıyı kurarken bunu net gördüm. Streaming notification kullanan uygulama firewall arkasında bazen sessizce kopuyor, sonra olay zinciri eksik kalıyordu. Hata mesajı da çok açıklayıcı değildi; klasik Exchange dünyasının nazlı yanlarından biri buydu. Bir noktada loglara bakıp “burada ne olmuş şimdi?” dediğimi hatırlıyorum… aynen öyleydi.
Çok konuştum, örnekle göstereyim.
Microsoft Graph burada güzel bir çizgi çekiyor: tek tip change notification, stateless yaklaşım ve webhooks üzerinden near-real-time teslimat. Bu sadeleşme kötü değil, baya iş görüyor (buna dikkat edin). Ama şunu da dürüstçe söyleyeyim: sadelik bazen size özgürlük vermez, sorumluluk verir. Yanı artık veri tutarlılığını sız daha bilinçli yönetiyorsunuz.
Push, Pull ve Streaming’in Kısa Hikâyesi
Push modelinde Exchange size haber veriyordu; pull modelinde sız gidip bakıyordunuz; streaming’de işe bağlantı açık kalıyor. Olaylar akıyordu. Kısacası, bunların her biri belirli iş yüklerinde hâlâ anlamlı olabilir ama kurumsal ölçekte bakım maliyeti hızla büyüyor. En çok da çok tenant’lı ya da yüksek hacimli ortamlarda bu çeşitlilik baş ağrısı yapabiliyor (ki bu çoğu kişinin gözünden kaçıyor)
Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.
Bak şimdi, Bence küçük ekipler için Graph’a geçiş çoğu zaman rahatlatıcı oluyor çünkü kod tabanı sadeleşiyor (inanın bana). Enterprise tarafta işe konu biraz farklı: burada sadece kod değil, gözlemleme, retry stratejisi, throttling yönetimi ve güvenlik sınırları da devreye giriyor. Yanı startup “tek webhook endpoint yeter” diyebilirken enterprise “o endpoint’in arkası nasıl ölçeklenecek?” diye soruyor (evet, doğru duydunuz)
| Model | Artı | Ekşi |
|---|---|---|
| EWS Push | Düşük gecikme | Public endpoint ihtiyacı |
| EWS Pull | Sade mantık | Sürekli sorgu yükü |
| EWS Streaming | Anlık akış hissi | Kırılgan bağlantılar |
| Graph Webhook | Sade ve modern yapı | Tutarlılık için ek tasarım gerekir |
Graph Bildirimleri Nasıl Düşünülmeli?
Şöyle ki, Microsoft Graph change notifications temelde HTTP POST ile geliyor. Olay olur olmaz endpoint’inize düşüyor ve sız de kendi iş akışınızı başlatıyorsunuz. Buradaki kritik nokta şu: bu bildirimler size “olay öldü” diyor, çoğu zaman “olayın büyük çoğunluk detayı budur” demiyor. İşte tam burada rich notifications devreye giriyor.
İşte tam da bu noktada devreye giriyor. CodeQL 2.25.6 ile Sessiz Ama Güçlü Güvenlik Sıçraması yazımızda bu konuya da değinmiştik.
Açıkçası, Rich notifications bana göre özellikle e-posta odaklı uygulamalarda fena değil, hatta bayağı iyi bir avantaj sağlıyor. Subject veya sender gibi bilgileri doğrudan alabiliyorsunuz. Böylece sırf detay çekmek için ikinci bir API çağrısı yapmak zorunda kalmıyorsunuz. Latency azalıyor, kullanıcı deneyimi toparlanıyor.
Ha bu arada bir gerçek var: Graph bildirimi almak başka şeydir, önü doğru yorumlamak başka şeydir. Notification kaybolabilir mi? Evet (ciddiyim). Sisteminizde kısa süreli kesinti olabilir mi? Olabilir! O yüzden delta query ile reconciliation yapmak şart gibi düşünün. Ben bunu AZ-305 hazırlığında da hep böyle anlatırım: mimariyi tek sinyal üzerine kurarsanız kırılgan olur. Azure Cosmos DB’de Partition Key Değiştirmek: Artık Daha Az Acı Veriyor yazımızda bu konuya da değinmiştik.
Neden Delta Query’yi Ciddiye Almak Lazım?
Delta query aslında olay sonrası denetim mekanizması gibi çalışıyor. Bildirım geldiğinde hemen işlem — ki bu tartışılır — yaparsınız; sonra delta ile kaçırdığınız kayıt var mı diye bakarsınız. Bu ikili yapı özellikle yüksek trafikli mailbox senaryolarında çok değerli oluyor çünkü webhook teslimatı mükemmel değil — zaten hiçbir bulut servisi kusursuz değil (evet, doğru duydunuz) Bu konuyla ilgili .NET 11 Preview 5: Sessiz Gelen Yenilikler, Büyük Etki yazımıza da göz atmanızı tavsiye ederim.
{
"step1": "Webhook ile change notification al",
"step2": "İlgili item için gerekirse rich data kullan",
"step3": "Belirli aralıklarla delta query çalıştır",
"step4": "Kaçan değişiklikleri reconcile et",
"step5": "Idempotent işlem tasarla"
}Bence burada en sık yapılan hata şu: ekipler webhook’u görünce iş bitmiş sanıyor. Sonra production’da iki bildirım kaçınca alarm çalıyor ama nedenini kimse bilmiyor oluyor… Bu konuda netim: idempotency yoksa migration yarım kalmıştır. Daha fazla bilgi için Azure DevOps’tan GitHub’a Kesintisiz Geçiş: ELM ile Yeni Dönem yazımıza bakabilirsiniz.
Büyük Kurumlarda Ne Fark Ediyor?
Küçük startup ortamlarında çoğu zaman tek servisle işi çözersiniz; birkaç queue, tek region ve basit retry yeterli olabilir. Ama bankacılıkta ya da — itiraz edebilirsiniz tabi — telekomda durum başka tabiî ki — itiraf edeyim, beklentimin üstündeydi —. Orada concurrency limiti, güvenlik politikaları ve operasyonel dayanıklılık meseleleri aniden ön plana çıkıyor.
Bi saniye — 2024 Mart ayında Logosoft’ta görüştüğümüz bir kamu müşterisinde tam da bunu yaşadık: mail tetiklemeli iş akışı vardı ama team aslında event processing platformu işletiyormuş gibi davranmak zorundaydı (evet biraz garip). O noktada Azure Event Hubs seçeneği ciddi rahatlama verdi çünkü notification akışını merkezî olarak toplamak ve tüketicilere dağıtmak kolaylaştı.
E tabi burada maliyet kısmını da konuşmak lazım. TL bazında düşündüğünüzde sadece API çağrıları ucuz görünebilir ama operasyonel saatlerin maliyeti pek ucuz değil. Bir servis gecesi bozulduğunda sabaha kadar iki kişinin ekran başında beklemesi… işte o tabloyu bütçeye yazmazsanız resim eksik kalır.
Maliyet ve Alternatifler
- Küçük ekipseniz önce webhook + delta query ile başlayın. — ciddi fark yaratıyor
- Bütçe kısıtlıysa Event Hubs yerine doğrudan queue tabanlı tamponlama deneyin.
- Büyük kurumdaysanız observability katmanını en baştan kurun.
- Tek noktaya bağımlılığı azaltmak için retry ve dead-letter planlayın.
Açık konuşayım, bazı ekipler Event Hubs duyunca direkt “kurumsal çözüm” diye atlıyor ama her problem o kadar büyük değil. Basit senaryoda fazla mühendislik de ayrı dert çıkarır. Mesela sadece birkaç mailbox izliyorsanız gereksiz yere karmaşık mimarı kurmayın; az bileşen çoğu zaman daha sağlamdır (şaşırtıcı ama gerçek)
Migrasyon İçin Pratik Yol Haritası
Lafı gevelemeden söyleyeyim: önce mevcut EWS kullanımınızı sınıflandırın. Push mu kullanıyorsunuz? Pull mu? Streaming mi? Her biri için hedef davranış farklı olacak çünkü Graph’ta birebir karşılık yok; yeni mimariyi buna göre çizmeniz gerekiyor.
Ben olsam ilk adımı şöyle atarım: hangi event gerçekten kritik, hangisi sadece bilgilendirme amaçlı önü ayırırım. Sonra subscription lifecycle kontrolünü ele alırım — expiration süresi dolmadan yenileme yapılacak mı? Eğer bu soru havada kalırsa production’da sessiz kopmalar yaşarsınız. Daha fazla bilgi için vcpkg Mayıs 2026 Güncellemesi: Sessiz Güç, Büyük Etki yazımıza bakabilirsiniz.
Aslında — dur bir saniye — önce şunu söyleyeyim: migration projelerinde teknik riskten önce süreç riski gelir.
Bu cümleyi boşuna kurmuyorum çünkü müşteri toplantılarında en çok orada tökezleniyoruz.
“Kim ownership alacak?”, “renewal job nerede koşacak?”, “monitöring alarmı kime gidecek?” soruları cevaplanmadan kod yazmaya başlamak bana göre acelecilik oluyor.
Graph’a geçişte asıl kazanım sadece modern API kullanmak değil; olayları yeniden düşünmek zorunda kaldığınız için sisteminizi temizlemenizdir.
Dikkat Etmeniz Gerekenler
Bak şimdi, Immutable IDs, item takibinde hayat kurtarıyor ama yanlış varsayım yaparsanız yine duvara toslarsınız. ID sabit diye her alan sabit sanmayın; mailbox taşıma veya yeniden eşleme durumlarında test şarttır. Ben bu konuyu ilk kez canlı ortamda gördüğümde ufak bir hayal kırıklığı yaşamıştım çünkü ekip sadece ID’ye güvenmişti, metadata değişimini kaçırmıştı.
Error handling tarafında işe kısa yol yok. Throttling geldiğinde geri çekilmek — itiraz edebilirsiniz tabi — lazım; exponential backoff olmadan devam etmek cloud-native dünyada pek hoş sonuç vermiyor. Bir de şunu ekleyeyim: logging’i fazla yapıp faydasız hâle getirmeyin, anlamlı correlation id üretin.
Kendi Sahadaki Notlarım ve Net Görüşüm
Bak şimdi, 2024 Temmuz’da İzmir’deki bir üretim firmasına yaptığımız değerlendirmede ekip “notification aldık mı tamamdır” kafasındaydı. Onlara delta reconciliation göstermemizle tablo değişti. Çünkü sistem düzgün çalışan günlerde herkes mutlu oluyor ama veri kaçınca kimse hatırlamıyor bile. İşin güzeli şu ki küçük düzeltmelerle oldukça sağlam hâle getirebildik.
Bence Microsoft’un yaptığı yönlendirme doğru yönde atılmış bir adım ama henüz ham olan yerler var. Mesela migration tooling tarafında bazı ekiplerin eli hâlâ manuel işlere gidiyor. Dokümantasyon iyi, fakat gerçek hayatta örnek mimariler biraz daha çoğalsa hiç fena olmazdı.
Sıkça Sorulan Sorular
EWS notification’dan Microsoft Graph’a geçmek zorunda mıyım?
Zorunda değilsin aslında, ama uzun vadede bence kesinlikle Graph’a geçmek mantıklı. Hani EWS eski bir mimariye bağlı kaldığı için yeni geliştirmelerde Graph çok daha iyi oturuyor.
Graph bildirimleri EWS kadar hızlı mı?
Açıkçası pek çok senaryoda gayet yakın bir performans veriyor. Yine de gerçek zamanlı bir şeyler bekliyorsan, rich notifications. Iyi tasarlanmış bir backend olmadan işler zorlaşabilir.
Delta query neden bu kadar önemli?
Doğrusu, Çünkü webhook’un kaçırdığı olayları telafi etmeni sağlıyor. Tecrübeme göre bunu hep sigorta poliçesi gibi anlatıyorum; yanı olmadan da idare edersin ama risk ciddi şekilde büyüyor.
Azure Event Hubs’ı ne zaman kullanmalıyım?
Mesela yük yüksekse, çok sayıda tüketici varsa ya da dağıtık bir işlem gerekiyorsa çok anlamlı oluyor. Ama tek servisli basit bir çözümde bence fazla kaçabilir.
Kaynaklar ve İleri Okuma
Microsoft Graph Change Notifications Overview
Microsoft Graph Webhooks Documentation
Açık konuşayım, Microsoft Graph Delta Query Overview
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