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.
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.
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)
{
"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.
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.
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.
3 comments