Microsoft Entra’da Sonradan Görülen Tutarlılıkla Yaşamak: Hayal Kırıklığı mı, Gerçekçi Bir Mimari mi?
Bir Anda Değişmeyen Sistemler: Neden Hâlâ “Görmüyorum” Diyoruz?
Son zamanlarda Microsoft Entra ile ilgili bana en sık gelen sorulardan biri şu öldü: “Abi, kullanıcıyı ekledim ama neden hemen göremiyorum? Bir şey mi yanlış gidiyor?” Emin olun, çoğu durumda sistemin başına bir iş gelmiş değil — öyle acil panik yapacak bir hata yok. Aslında bunun sebebi gayet teknik. Çok basit anlatılabilir; çünkü Microsoft Entra gibi büyük altyapılarda yapılan değişiklikler tüm bölgelerde pat diye görünmüyor. Adı üstünde: sonradan görülen tutarlılık (eventual consistency). Şaşırtıcı geliyor, evet, ama şöyle düşünün…
“Aslında gerçek dünyada da böyle bir bekleyiş var. Sipariş verdiğin pizza hani? Mutfaktan çıkıp sana ulaşması, hop diye olmuyor.”
Bu mevzu önemli çünkü genelde BT tarafında kod yazıp saniyesinde sonucu almak istiyoruz ya (evet, doğru duydunuz). Arkada işler pek o kadar hızlı değil. Dünyanın dört bir yanında replikalar var, asenkron işliyor her şey ve bazen bilgiler anca yayılıyor.
Entra’nın Sonradan Görülen Tutarlılığı Ne Demek? (Örneklerle)
Bunu geçen ay yaşadım, tam örneklik olay! Büyük bir bankada Active Directory’den Entra’ya kimlik senkronizasyonu için PowerShell modülü geliştirirken kullanıcı oluşturdum ve Get-MgUser‘la okumaya kalktım… Cevap? Kullanıcı ortada yok! Tuhaf mı geldi? Korkmayın — kodda sorun yoksa bu normaldir.
- Kullanıcı kaydını atıyorsun → Yazma cevabı dönüyor, işlemin tamam diyor.
- Hemen okuma yapınca → Ya yeni kayıt gözükmüyor ya eski data geliyor.
- Birkaç dakika geçince → Her şey yerli yerine oturmuş oluyor.
Şöyle söyleyeyim, İlk başta ben de şaşırmıştım. En çok da 2019’da Logosoft’ta çalışırken müşterinin onboarding sürecinde gece boyu hatayı çözmek için uğraşmışlığım var! Halbuki sistem böyle tasarlanmış… Uzatmaya gerek yok:
Büyük dağıtık platformlarda güncellemeler arka planda asenkron çoğaltılır. Yanı veri yazıldıktan sonra aslında bazı kopyalar hâlâ eski olabilir.
Peki, Neden Böyle Bir Tasarım?
Sebepler net:
- Küresel erişimi olan devasa müşteri kitlesi
- Acil durumlarda duraksamadan çalışabilmesi şart!
- Mümkün olan en hızlı okuma reaksiyonu (lokal veritabanından)
Düşünün — her değişiklik saniyesinde her yerde aynı olsa hız yerle yeksan olurdu. Hatta bazen felaket olursa diğer kıtalardaki sistem hiç açılmazdı!
Tutarsızlığa Dair Sık Karşılaşılan Senaryolar ve Gerçek Hayattan Örnekler
Kullanıcı/Oluşum Kaydı “Var mı Yok mu?” Tartışmaları
Bundan birkaç sene önce devasa bir e-ticaret şirketinde SAP’den Microsoft Graph API’ye toplu kullanıcı kaydı atarken sabah saatlerinde yeni eklenenlerin %10’u ilk API çağrısında çıkmadı! Ekipten biri hemen “API bozuk!” dedi… Halbuki sistemin çalışma biçiminden kaynaklı gecikme söz konusu.
“Not Found” Hatası ile Dans Etmek
Aynısı daha geçen hafta başıma geldi; Azure Functions üzerinde otomasyon pipeline’ında yeni App Registration ID’sını hemen çekmeye çalışınca “404 Not Found” fırladı karşıma. Eskiden olsa ikinci kez yaratmak isterdim — rezalet olurdu tabiî! Şimdi öğrendim:
# Yanlış Pratik!
$user = New-MgUser - DisplayName "Test User"...
$readBack = Get-MgUser - UserId $user.Id
if (!$readBack) { throw "HATA! Kullanıcı görünmüyor." }
# Doğru Yol:
$user = New-MgUser - DisplayName "Test User"...
$id = $user.Id # Elimizde zaten!
# Gerekirse biraz bekleyip tekrar oku
Delegated Access vs App-Only Erişimde Tutarlılık Farkları
Dikkat edilecek kritik noktayı kaçırmayın! Eğer uygulamanız delegated access (yanı kullanıcı oturumu üzerinden) gidiyorsa aynı zincirde tutarlılık genelde daha iyi hissediliyor; app-only işe sonuçlar tahmin edilmez hâle gelir çünkü başka replikalara düşebilirsiniz. SQL Server 2025’te JSON Depolama: Artık Sadece NVARCHAR’a Mahkûm Değiliz! yazımızda bu konuya da değinmiştik. ABD Devletine Açılan Sır Kapısı: Azure Top Secret Bulutta Yapay Zekâ ve Verinin Yeni Çağı yazımızda bu konuya da değinmiştik.
Tutarsızlıkla Yaşamanın Yolları ve İşe Yarayan Tasarım Kalıpları
| Doğru Yaklaşımlar | Yanlış Yaklaşımlar |
|---|---|
| ID ve dönen veriyi cache’lemek Yazmadan sonra tekrar okuyup doğrulamak yerine response’daki ID’yi saklayın. Akışı kısa tutmak Retry gerekirse exponential backoff kullanın |
Anlık görüntü ummak Her hareketin sonucunu saniyesinde görmek istemek boşuna. Aynı kaydı tekrar yaratmak Düşünmeden retry yapmak |
Neden Anında Görünürlük Beklemeyin?
Sürekli söylüyorum — özellikle kurumsal projede anlık yansıma beklerseniz moraliniz bozulur. Blogumda (Data API Builder Zincirleme ile Farklı Sistemleri Birleştirmek) başka distribüe edilmiş veritabanlarında da benzerlerini anlatmıştım; Entra’daki tutarsızlık orada da karşımıza çıkıyor resmen. Fiziksel Sistem Tasarımında Yeni Dönem: Azure MSWB ile Geleceğe Bakış yazımızda bu konuya da değinmiştik.
Pratikte Olası Senaryolar ve Tavsiyelerim (Startup’tan Kurumlara)
Küçük Startup için Senaryo:
Diyelim iki kişilik ekip olarak ardışık test yapıyorsunuz; yeni kullanıcı ekliyorsunuz hızlıca ve demo sunacaksınız… Kodunuzda esneklik lazım şurada: Veritabanına Akıllı Soru Sorabilen AI: Data API Builder MCP ile Güvenli Analiz Dönemi yazımızda bu konuya da değinmiştik.
- Kullanıcının ID’sını mutlaka response’dan alıp kenara yazın.
- Anlık doğrulama yerine arada 30-60 sn gecikmeli kontroller koyun.
- Aksi takdirde demo sırasında “kullanıcı bulunamadı!” krizi yaşanabilir – tecrübe konuşuyor burada!
Büyük Kurumsal Yapıda Ne Değişiyor?
Şöyle söyleyeyim, Büyük projelerde iş baya karmaşıklaşıyor… Hele bir de bankalarda/telekomda batch job’lar gece yarısı koşar. Yüzbinlerce obje akışı olur. Burada concurrency yönetimi bambaşka dert — mesela exponential backoff polling gerekir, idempotency şart olur artık. İstanbul’da 2022’de yürüttüğümüz finans projesinde sırf bu yüzden workflow engine’i sıfırdan yazdık; ardışık retry’ların datayı bozmaması için zorundaydık! Bu konuyla ilgili Mart 2026 Azure SDK Güncellemeleri: Sürprizler, Detaylar ve Gerçek Hayat Yansımaları yazımıza da göz atmanızı tavsiye ederim.
Sadece create/read/update için değil; grup üyelikleri veya uygulama rolleri verirken de aynı tutarsızlık başınıza gelebilir.
SIEM loglarını karşılaştırırken işlem sürelerine dikkat edin; gecikmeler sandığınızdan fazla olabilir.
Teknik İpuçları & Kod Pratiği:
# Exponential backoff polling örneği (PowerShell)$retry = 0
$found = $false
do {
$retry++
try {
$user = Get-MgUser - UserId $userId
if ($user) { $found = $true }
} catch {
Start-Sleep - Seconds ([math]::Pow(2,$retry)) # 2,4,8..sn bekle
}
} while (-not $found - and $retry - lt 5)
if (-not $found) { Write-Warning "Hala bulamıyorum:/" }
Peki Tüm Bunların Alternatifi Yok mu?
Bazen eğitimin ortasında biri el kaldırıyor:”Neden strong consistency kullanılmıyor abi?” Yanı neden yapılan işlem her yerde anında gözükmüyor? Kısaca söyleyeyim:
- Eğer küresel ölçek hedefliyorsak başka yolu neredeyse yok – sonradan görülen tutarlılık kaçınılmaz.
- Tam zamanlı güncelleme denersek hem performans erir hem felaket senaryosunda dümdüz kalırız!
- Kimi küçük serviste strong consistency mümkün ama farklı mimarı gerektirir — örnek Azure SQL DiskANN Vektör İndeksleriyle ilgili yazımda bahsetmiştim;, orası apayrı konu.
Sistemi Sağlamlaştırmak İçin Neye Dikkat Etmeli?
Cevapları Doğru Okuyun ve Cache Kullanın!
Şöyle söyleyeyim, Create call sonrası dönen cevapta ihtiyaç duyduğunuz tüm property’ler hazırdır zaten – sürekli yeniden okuma takıntısından kurtulun derim! Biz kendi uygulamalarımızda bunu alışkanlık hâline getirdik. Bayağı işe yaradı.
Workflow’u Basitleştirin — Fazladan Adımlardan Kaçının!
Mümkünse süreçleri sadeleştirip tek adımda işi bitirin; misal yarat + oku + güncelle mantığındansa parametrelerin tamamını tek seferde vererek işinizi halledin.
“Bazen tek satırlık iyileştirme saatlerce debug’a bedel oluyor.”
Tahmin Edemediklerim ve Hayal Kırıklıkları…
Açık açık itiraf edeyim; ilk zamanlar Microsoft’un bu çaplı sistemlerde niye daha modern instant consistency kurmamış olduğunu anlamamıştım! Ama test ettikçe kurumsalda gördükçe bunun pratikte imkânsızlığına inandım – hayal kırıklığı oluyor bazen ama sebebini bildiğinde sınırını kontrol etmek kolaylaşıyor.
Çoğu müşteri toplantısında şu cümleyi duymuşumdur:
“Neden dün yaptığım değişiklik bugün hâlâ görünmüyor?”
Net yanıt? Sistem doğası gereği mümkün değil.
Bunu bilip kabullenince işler rayına oturuyor.
Daha detay isteyenlere blogdan tavsiye:
Sıkça Sorulan Sorular
Microsoft Entra’da yaptığım değişiklik neden hemen gözükmüyor?
Sistem global asenkron replikasyon kullanıyor — yapılan değişikliğin tüm kopyalara yayılması kimi zaman dakikaları bulabiliyor, aralıklarla gecikme olağan kabul edilmeli.
Başarılı write yanıtı aldıktan sonra tekrar okuma yapmak doğru mu?
Doğrusu, Eğer response’ta ihtiyacınız olan veri varsa ekstra read gereksizdir. Aceleci sonuç size yanıltıcı bilgi getirir – cache kullanımı en sağlıklı çözüm diyebilirim.
“404 Not Found” hatası aldığımda ne yapmalıyım?
Vallahi, Birkaç kere artan aralıklarla deneyin (exponential backoff en güzeli). Çoğunlukla hata sonradan görülen tutarlılıkla ilgili olur – telaşa kapılmadan sabredin yeter!
Tutarlılığı garanti etmek için hangi erişim tipini seçmeliyim?
Daha iyi konsistensi isterseniz delegated access’e yönelin; app-only çağrıda veri tutarlılığı hiçbir şekilde kesinleşmez. Farklı replikaya düşebilirsiniz…
Kaynaklar ve İleri Okuma
- Microsoft Resmî Blog – Designing for Eventual Consistency for Microsoft EntraAzure Active Directory Scenario Design GuidanceMicrosoft Graph Transient Errors and Throttling Docs
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.
