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: 💡 Bilgi: Büyük dağıtık platformlarda güncellemeler arka planda asenkron çoğaltılır. Yani 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ı!

Microsoft Entra’da Sonradan Görülen Tutarlılıkla Yaşamak: Hayal Kırıklığı mı, Gerçekçi Bir Mimari mi? -

⏱️ 6 dk okuma📅 27 Mart 2026

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 oldu: “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:

💡 Bilgi:
Büyük dağıtık platformlarda güncellemeler arka planda asenkron çoğaltılır. Yani 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’sini hemen çekmeye çalışınca “404 Not Found” fırladı karşıma. Eskiden olsa ikinci kez yaratmak isterdim — rezalet olurdu tabii! Ş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 (yani kullanıcı oturumu üzerinden) gidiyorsa aynı zincirde tutarlılık genelde daha iyi hissediliyor; app-only ise sonuçlar tahmin edilmez hale gelir çünkü başka replikalara düşebilirsiniz. SQL Server 2025’te JSON Depolama: Artık Sadece … yazımızda bu konuya da değinmiştik. ABD Devletine Açılan Sır Kapısı: Azure Top Secr… 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 Ekstra adımları azaltıp işi sadeleştirin. Retry gerekirse exponential backoff kullanın Okuma gerekiyorsa deneme aralarını artırarak tekrar deneyin (kod aşağıda).	Anlık görüntü ummak Her hareketin sonucunu saniyesinde görmek istemek boşuna. Aynı kaydı tekrar yaratmak “Bulamadım” deyince yeniden oluşturursanız duplicate problemi çıkar. Düşünmeden retry yapmak Idempotent olmayan işlemlerle aynı objeyi defalarca bozmak risklidir.

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
Ekstra adımları azaltıp işi sadeleştirin.

Retry gerekirse exponential backoff kullanın
Okuma gerekiyorsa deneme aralarını artırarak tekrar deneyin (kod aşağıda).

Anlık görüntü ummak
Her hareketin sonucunu saniyesinde görmek istemek boşuna.

Aynı kaydı tekrar yaratmak
“Bulamadım” deyince yeniden oluşturursanız duplicate problemi çıkar.

Düşünmeden retry yapmak
Idempotent olmayan işlemlerle aynı objeyi defalarca bozmak risklidir.

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 M… 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… yazımızda bu konuya da değinmiştik.

Kullanıcının ID’sini 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,… yazımıza da göz atmanızı tavsiye ederim.

💡 Bilgi:
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?” Yani 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ı mimari 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 haline 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 sinirini 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 hala 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:

Polyglot Veritabanı Maliyeti yazısı

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…