Nihai tutarlılık çoğunlukla daha hızlı, daha erişilebilir uygulamalar sağlar. Ne zaman uygun olduğunu, nasıl tasarlanacağını ve ne zaman daha güçlü garantilere ihtiyaç olduğunu öğrenin.
“Tutarlılık” basit bir sorudur: iki kişi aynı veriye baktığında aynı şeyi aynı anda mı görüyor? Örneğin, gönderim adresinizi değiştirdiğinizde profil sayfanız, ödeme ekranınız ve müşteri destek ekranı yeni adresi hemen gösterecek mi?
Nihai tutarlılık ile cevap: her zaman hemen değil—ama bir süre sonra uyuşacak. Sistem, kısa bir gecikten sonra her kopyanın aynı en güncel değerde birleşmesini sağlar.
Bir değişiklik kaydettiğinizde, bu güncellemenin yol kat etmesi gerekir. Büyük uygulamalarda veri tek bir yerde saklanmaz. Veri çoğaltılır—farklı sunucularda veya bölgelerde birden çok kopya ("replika") tutulur.
Neden kopya tutulur?
Bu replikalar kusursuz şekilde aynı anda güncellenmez. Kullanıcı adınızı güncellediğinizde, bir replikada değişiklik anında uygulanırken bir başkası biraz sonra uygulayabilir. O pencere içinde bazı kullanıcılar (ya da farklı bir ekrandan siz) kısa süreli eski değeri görebilir.
Nihai tutarlılık şüphe uyandırabilir çünkü bilgisayarların kesin olduğunu düşünmeye alışığız. Ancak sistem güncellemenizi kaybetmiyor—erişilebilirliği ve hızı önceliklendiriyor, sonra diğer kopyaların yetişmesine izin veriyor.
Faydalı çerçeve şudur:
Bu “yakında” milisaniye, saniye veya nadiren kesintiler veya yoğun yük nedeniyle daha uzun olabilir. İyi ürün tasarımı bu gecikmeyi anlaşılır kılar ve nadiren fark edilir hale getirir.
Anında anlaşma kulağa ideal geliyor: her sunucu, her bölgede, tam olarak aynı anda aynı veriyi gösterecek. Küçük, tek veritabanlı uygulamalarda bu çoğu zaman mümkün olabilir. Ama ürünler büyüdükçe—daha fazla kullanıcı, daha fazla sunucu, daha fazla lokasyon—“her yerde mükemmel senkron” pahalı ve bazen gerçekçi olmaz.
Bir uygulama birden fazla sunucu veya bölge üzerinde çalıştığında, verinin ağ üzerinden yol alması gerekir; ağ gecikmesi ve bazen hatalar olur. Çoğu istek hızlı olsa bile, en yavaş bağlantılar (veya geçici olarak bağlantısı kesilmiş bir bölge) herkesin en yeni güncellemeyi aldığını doğrulamak için ne kadar beklemeniz gerektiğini belirler.
Sistem anında anlaşma konusunda ısrar ederse şunları yapmak zorunda kalabilir:
Bu, küçük bir ağ sorununun kullanıcı için fark edilir bir probleme dönüşmesine neden olabilir.
Anında tutarlılığı garanti etmek için birçok tasarım, verinin commit sayılmadan önce koordinasyon—etkili olarak grup kararı—gerektirir. Koordinasyon güçlüdür, fakat tur sayısını arttırır ve performansı daha az öngörülebilir yapar. Önemli bir replikasyon yavaşsa, bütün işlem onunla yavaşlar.
Bu takas genellikle CAP teoremi ile özetlenir: ağ bölünmeleri altında sistemler ya kullanılabilirliği seçmeli ya da katı tutarlılığı seçmelidir. Birçok gerçek uygulama yanıt vermeye devam etmeyi tercih eder.
Replikasyon yalnızca daha fazla trafiği karşılamak için değildir. Aynı zamanda arızalara karşı sigortadır: sunucular çöker, bölgeler bozulur, dağıtımlar yanlış gidebilir. Replikalar sayesinde uygulama, sistemin bir kısmı sağlıksız olsa bile siparişleri, mesajları ve yüklemeleri kabul etmeye devam edebilir.
Nihai tutarlılığı seçmek genellikle şu ikiden birinin bilinçli tercihidir:
Çoğu ekip kısa süreli farklılıkları kabul eder çünkü alternatif en kötü zamanlarda (pik trafik, kampanyalar, olaylar) daha yavaş deneyimler veya kesintiler demektir.
Nihai tutarlılık, aynı uygulamayı birden fazla yerden kullandığınızda en kolay fark edilen şeydir.
Telefonunuzda bir gönderiyi “beğenirsiniz”. Kalp ikonu hemen dolar ve beğeni sayısı 10'dan 11'e çıkabilir.
Birkaç dakika sonra aynı gönderiyi dizüstünüzde açtığınızda… hâlâ 10 beğeni gösteriyor olabilir. Ya da kalp henüz dolmamış olabilir. Uzun vadede hiçbir şey “bozuk” değildir—güncelleme sadece her veritabanı kopyasına ulaşmamıştır.
Çoğu zaman bu gecikmeler kısa olur (çoğunlukla saniyenin kesirleri). Ama ağlar yavaşladığında, bir veri merkezi geçici olarak ulaşılamadığında veya servis olağandışı yüksek trafikle uğraşıyorsa sıçrayışlar yaşanabilir. Bu anlarda sistemin farklı parçaları geçici olarak farklı durumlarda olabilir.
Kullanıcı açısından nihai tutarlılık genellikle şu kalıplarla görünür:
Bu etkiler sayaçlar (beğeniler, görüntülemeler), etkinlik akışları, bildirimler ve arama sonuçları gibi genişçe çoğaltılan yerlerde daha belirgin olur.
Nihai tutarlılık “her şey serbest” demek değildir. Sistem, yakınsama için tasarlanır: geçici kesinti geçtikten ve güncellemeler yayıldıktan sonra her replikada aynı son durum oluşur.
“Beğeni” örneğinde, her iki cihaz da sonunda sizin gönderiyi beğendiğinizi ve sayının 11 olduğunu kabul edecektir. Zamanlama değişebilir, ama varış noktası aynıdır.
Uygulamalar bu kısa süreli tutarsızlıkları düşünerek—açık UI geri bildirimi, mantıklı yenileme davranışı ve korkutucu hata mesajlarından kaçınma—tasarladığında çoğu kullanıcı altta neler olduğunun farkına bile varmaz.
Nihai tutarlılık bir takastır: sistem farklı yerlerde kısa süreli farklı veri gösterebilir, ama bunun karşılığında çok pratik avantajlar sağlar. Birçok ürün için bu avantajlar, özellikle kullanıcılar bölgelere yayılmış ve birkaç replika varsa, anlık uzlaşmadan daha önemlidir.
Replikasyon ile veriler birden fazla yerde yaşar. Bir node veya hatta bir bölge sorun yaşarsa diğer replikalar okumaları ve yazmaları sunmaya devam edebilir. Bu, daha az “tamamen kapalı” olay ve kısmi arızalar sırasında daha az bozuk özellik demektir.
Herkesin aynı anda anlaşmasını beklemek yerine uygulama çalışmaya devam eder ve sonra yakınsama sağlanır.
Her yazmayı uzak sunucularla koordine etmek gecikme ekler. Nihai tutarlılık bu koordinasyonu azaltır, böylece sistem genellikle:
Sonuç daha akıcı bir his: sayfa yüklemeleri, zaman çizelgesi yenilemeleri, beğeni sayıları ve stok sorguları çok daha düşük gecikmeyle sunulabilir. Evet, bu bayat okumalar yaratabilir; ama UX kalıpları genelde yavaş, engelleyen isteklere kıyasla bunları yönetmeyi kolaylaştırır.
Trafik arttıkça katı küresel uzlaşma koordinasyonu bir darboğaza dönüştürebilir. Nihai tutarlılık ile replikalar iş yükünü paylaşır: okuma trafiği yayılır ve yazma verimi, düğümler her zaman bölgeler arası onay beklemediği için iyileşir.
Büyük ölçekte bu, “daha fazla sunucu ekle ve daha hızlı olur” ile “daha fazla sunucu ekle koordinasyon zorlaşır” arasındaki farktır.
Sürekli küresel koordinasyon daha pahalı altyapı ve dikkatli ayar (global kilitler, eşzamanlı replikasyon vb.) gerektirebilir. Nihai tutarlılık, daha standart replikasyon stratejileri ve daha az “herkes hemen aynı fikir olmalı” mekanizması kullanarak maliyetleri düşürebilir.
Daha az koordinasyon gerekliliği ayrıca hata ayıklanacak arıza modlarını azaltabilir—büyürken performansı daha öngörülebilir tutmayı kolaylaştırır.
Nihai tutarlılık, kullanıcının “yaptım” ile “herkes görüyor” arasında küçük bir gecikmeyi tolere edebildiği, özellikle verinin yüksek hacimli ve güvenlik kritik olmadığı durumlarda en iyi çalışır.
Beğeniler, görüntülemeler, takipçi sayıları ve gönderi göstergeleri klasik örneklerdir. Eğer “Beğen”e bastığınızda sayı hemen sizde güncelleniyorsa, başkasının birkaç saniye (yoğun trafikte birkaç dakika) boyunca eski sayıyı görmesi genelde sorun yaratmaz.
Bu sayaçlar genellikle toplu güncellenir veya asenkron işleme tabi tutulur, böylece uygulamalar hızlı kalır. Önemli olan küçük bir farkın kullanıcının kararını anlamlı şekilde değiştirmemesidir.
Mesaj sistemleri çoğunlukla teslim makbuzlarını (“gönderildi”, “teslim edildi”, “okundu”) gerçek ağ teslim zamanından ayırır. Bir mesaj telefonunuzda anında “gönderildi” görünebilir, alıcının cihazı bağlantı, arka plan kısıtlamaları veya routing nedeniyle biraz sonra alabilir.
Benzer şekilde push bildirimleri gecikebilir veya farklı sırada gelebilir; uygulama eninde sonunda yakınsama sağladığı ve çoğaltma sırasında çoğaltılmış veya eksik mesajlardan kaçındığı sürece kullanıcılar bunu normal karşılar.
Arama sonuçları ve öneri karuselleri genellikle yazmalardan sonra yenilenen indekslere dayanır. Bir ürünü yayınlayabilir, bir profili güncelleyebilir veya bir gönderiyi düzenleyip aramada hemen görünmeyebileceğini görebilirsiniz.
Kullanıcılar genelde aramayı “yakında güncellenecek” olarak anlar; sistem yazma hızını ve daha ölçeklenebilir aramayı korumak için küçük bir tazelik boşluğu kabul eder.
Analitik genellikle dakikalar, saatler veya gün bazında işlenir. Panolarda “son güncelleme” ibaresi sıkça görülür çünkü gerçek zamanlı ve tamamen doğru sayılar pahalı ve genelde gereksizdir.
Çoğu ekip için bir grafiğin gerçeğin biraz gerisinde olması kabul edilebilirdir—önemli olan eğilimlerin ve kararların güvenilir olmasıdır.
Nihai tutarlılık, biraz geride olmanın sonucu değiştirmediği durumlarda makul bir takastır. Ancak bazı özelliklerin katı güvenlik ve doğruluk gereksinimleri vardır: sistem hemen aynı fikirde olmalı, sonra değil. Bu alanlarda bayat bir okuma sadece kafa karıştırıcı değil, gerçek zarar verebilir.
Ödemeler, transferler ve saklanan bakiye işlemleri “yakında düzelecek” yaklaşımına dayanamaz. Eğer iki replik geçici olarak farklıysa, çift harcama (aynı fonun iki kez kullanılması) veya istemeden limit aşımı riski vardır. Kullanıcı bir satın alma izin verebilecek bir bakiye görebilir ama para aslında başka yerde taahhütlü olabilir.
Parasal durumları değiştiren işlemler için ekipler genellikle güçlü tutarlılık, serileştirilebilir işlemler veya sıkı sıralamaya sahip tek yetkili bir defter servisi kullanır.
Bir katalog tarama sırasında biraz bayat stok sayısı tolere edilebilir. Ancak ödeme ekranında değil. Sistem eski replikaya dayanarak “stokta” gösterirse fazla satış (oversell) olur ve sonrasında iptaller, iade ve destek işleriyle uğraşmak gerekir.
Yaygın bir ayrım: ürün sayfalarında nihai tutarlılık, ancak ödeme sırasında doğrulanmış rezervasyon (veya atomik azaltma) kullanılır.
Erişim kontrolünün kabul edilebilir gecikmesi neredeyse sıfırdır. Bir kullanıcının erişimi geri alındıysa, bu iptal hemen uygulanmalı; aksi takdirde kullanıcı veri indirebilir, ayarları düzenleyebilir veya yönetici işlemleri yapabilir.
Bu parola sıfırlama, token iptali, rol değişikliği ve hesap askıya alma gibi durumları kapsar.
Denetim izleri ve uyum kayıtları genellikle sıkı sıralama ve değişmezlik gerektirir. Olayları “nihai” olarak yansıtması veya bölgeler arasında olayları yeniden sıralaması soruşturmaları ve düzenleyici gereksinimleri bozabilir.
Bu durumlarda ekipler eklenebilir-only depolama, tahrifata karşı kanıtlı loglar ve tutarlı zaman damgaları/sıra numaralarını tercih eder.
Geçici bir uyuşmazlık geri döndürülemez yan etkilere yol açıyorsa (para hareketi, mal sevki, erişim verilmesi, yasal kayıt değişikliği), kaynağın kendisi için nihai tutarlılığı kabul etmeyin. Bunun yerine türetilmiş görünümler (panolar, öneriler, arama indeksleri) için nihai tutarlılığı kullanın.
Nihai tutarlılık kullanıcıya “rastgele” hissettirmemeli. Püf nokta, ürünü ve API’ları öyle tasarlamaktır ki geçici uyuşmazlık beklenen, görünür ve kurtarılabilir olsun. İnsanlar ne olduğunu anladığında—ve sistem güvenle yeniden deneme yapabildiğinde—veri halen arka planda yaklaşıyor olsa bile güven artar.
Küçük bir metin çok sayıda destek talebini engeller. "Kaydediliyor…", "Az önce güncellendi" veya "Bir dakika sürebilir" gibi nazik durum sinyalleri kullanın.
Bu en iyi şekilde UI'nin aşağıdakileri ayırt etmesiyle çalışır:
Örneğin adres değiştirdikten sonra "Kaydedildi—tüm cihazlara senkronize ediliyor" göstermek, güncellemenin anında her yerde olduğunu iddia etmekten daha dürüsttür.
İyimser UI, beklenen sonucu hemen gösterir—çünkü çoğu zaman o gerçekleşecektir. Bu, replikasyon birkaç saniye sürse bile uygulamaları hızlı hissettirir.
Güvenilir tutmak için:
Anahtar, iyimserlik değil—kısa süre sonra gelecek görünür bir "makbuz"tur.
Nihai tutarlılıkta zaman aşımı ve yeniden denemeler normaldir. Bir kullanıcı "Öde"ye iki kez basarsa veya mobil uygulama sinyal kaybedip yeniden denemek isterse, çift ücretlendirme veya çift sipariş istemeyiz.
Idempotent işlemler, "aynı isteği tekrarlamak"ın aynı etkiyi üretmesini sağlar. Yaygın yaklaşımlar:
Bu, yeniden denemenin korkutucu değil rutin olmasını sağlar.
İki değişiklik sistem tam uzlaşmadan önce olursa çakışmalar ortaya çıkar—örneğin iki kişi aynı profil alanını aynı anda düzenler.
Genel olarak üç seçenek vardır:
Ne seçerseniz seçin, davranışı tahmin edilebilir kılın. Kullanıcılar gecikmeyi tolere edebilir; sürprizleri tolere edemezler.
Nihai tutarlılık genellikle kabul edilebilir—ama yalnızca kullanıcıların uygulamanın "yaptığını unuttuğunu" hissetmemesi durumunda. Hedef: kullanıcının beklediğiyle sistemin güvenle garanti edebildiği arasında uyum kurmak.
Bir kullanıcı profilini düzenlediyse, yorum yaptıysa veya adres güncellediyse, bir sonraki ekran kendi değişikliğini yansıtmalıdır. Bu kendi yazdığını okuma fikridir.
Takımlar genellikle bunu sağlar:
Sistem herkesi hemen eşleştiremese bile aynı kullanıcı oturumu boyunca tutarlı bir hikaye görebilir.
Örneğin bir gönderiyi beğendiğinizde, replikalar hafifçe uyumsuz olsa bile oturumunuz beğenili/ beğenilmemiş şeklinde gidip gelmemeli.
Mümkünse kullanıcının isteklerini yakın zamanda yazmasını kabul eden "bilinen" bir replikaya yönlendirin—buna bazen sticky session denir.
Bu veritabanını anında tutarlı yapmaz ama replikalar arası beklenmedik geçişleri azaltır.
Bu taktikler algıyı iyileştirir ve karışıklığı azaltır, ama her durumu çözmez. Kullanıcı başka bir cihazda oturum açarsa, bir link paylaşıp başkasıyla açarsa veya bir failover sonrası yenilerse yine eski veri görebilir.
Ürün tasarımı da yardımcı olur: "Kaydedildi" onayları gösterin, iyimser UI'yi dikkatle kullanın ve herkesin hemen göreceğini garanti etmiyorsanız "Herkes hemen görür" gibi ifadelerden kaçının.
Nihai tutarlılık "kur ve unut" değildir. Buna dayanan ekipler tutarlılığı ölçülebilir bir güvenilirlik özelliği olarak ele alır: "yeterince taze" olmanın ne demek olduğunu tanımlar, gerçek durum hedeflerden sapınca kaydeder ve sistem geride kaldığında eylem planı vardır.
Pratik bir başlangıç, bir yazmanın bir yerden diğer yerlere yayılması için SLO belirlemektir. Ekipler genellikle ortalamalar yerine yüzdelikler (p50/p95/p99) kullanır; çünkü uzun kuyruk kullanıcıların dikkatini çeker.
Örneğin: "güncellemelerin %95'i bölgeler arası 2 saniye içinde görünür, %99'u 10 saniye içinde." Bu sayılar mühendislik kararlarını (batch boyutları, yeniden deneme politikaları, kuyruk ölçüleri) ve ürün kararlarını (senkronize göstergesi gösterilip gösterilmeyeceği) yönlendirir.
Sistemi dürüst tutmak için ekipler sürekli olarak şunları loglar ve ölçer:
Bu metrikler normal gecikmeyi, takılmış tüketici, aşırı yüklü kuyruk veya başarısız ağ bağlantısı gibi daha derin bir problemi ayırt etmeye yardımcı olur.
İyi uyarılar kullanıcı etkisini öngören desenlere odaklanır:
Amaç, "geri kalıyoruz" durumunu "kullanıcılar çelişkili durumlar görüyor" haline gelmeden yakalamaktır.
Ekipler ayrıca bölünmeler sırasında nasıl zarifçe azalma yapılacağını planlar: okumaları "en muhtemel taze" replikaya yönlendirmek, riskli çok adımlı akışları devre dışı bırakmak veya "Değişiklikler bir dakika içinde görünebilir" gibi net bir durum göstermek. Oynatma kitapları baskı altında bu kararları tekrarlanabilir kılar, doğaçlama yapılmasını engeller.
Nihai tutarlılık bütün ürünü kapsayan evet/hayır kararı değildir. Başarılı uygulamalar modelleri karıştırır: bazı işlemler anlık uzlaşma gerektirir, bazıları birkaç saniye sonra çözülmeye elverişlidir.
Pratik bir karar yöntemi: yanlış olmanın gerçek maliyeti nedir?
Eğer kullanıcı biraz eski bir beğeni sayısı görürse zararı küçüktür. Eğer yanlış hesap bakiyesi panik ya da finansal kayba yol açabilecekse sonuç ağır olur.
Bir özelliği değerlendirirken şu dört soruyu sorun:
Eğer güvenlik/para/güven sorularından herhangi birine "evet" ise, o operasyon için (veya en azından "commit" adımı için) daha güçlü tutarlılığa yönelin. Eğer geri alınabilirlik yüksekse ve etki düşükse nihai tutarlılık genellikle iyi bir tercih olur.
Yaygın bir desen, çekirdek işlemi güçlü tutarlılıkla tutup çevresindeki özelliklere nihai tutarlılık vermektir:
Seçiminizi yaptıktan sonra bunu basit bir dille yazın: ne bayat olabilir, ne kadar süreyle, ve kullanıcılar bu süre boyunca ne görmeli. Bu, ürün, destek ve QA'nın tutarlı davranmasına yardım eder ("bu bir hata mı?" vs "biraz sonra eşleşecek" tartışmasını önler). Özellikle hızlı giderken bu kararları erkenden standartlaştırmak işe yarar. Örneğin Koder.ai kullanan takımlar yeni servisleri planlarken hangi uç noktaların güçlü tutarlılık gerektirdiğini (ödeme, izinler) ve hangilerinin nihai olabileceğini açıkça tanımlar. Bu yazılı sözleşme, idempotency anahtarları, yeniden deneme güvenli handler'lar ve net "senkronize ediliyor" UI durumları gibi doğru kalıpları üretmeyi kolaylaştırır.
Nihai tutarlılık "daha kötü" bir tutarlılık değil—bilinçli bir takastır. Birçok özellik için, uygulamanın kullanıcıya hissettirdiği deneyimi iyileştirebilir: sayfalar hızlı yüklenir, eylemler nadiren başarısız olur ve uygulama parçalar baskı altındayken bile erişilebilir kalır. Kullanıcılar genelde "çalışıyor ve hızlı" olmayı, tüm ekranların anında güncellenmesinden daha fazla değerli bulur; yeter ki ürün tahmin edilebilir davransın.
Bazı kategoriler yanlışlıkla sapma yaşarsa maliyeti yüksek olduğu için daha katı kurallar gerektirir. Güçlü tutarlılığı (veya dikkatle kontrol edilen işlemleri) şunlar için kullanın:
Diğer her şey için—akışlar, görüntüleme sayıları, arama sonuçları, analitik, öneriler—nihai tutarlılık genellikle makul bir varsayımdır.
En büyük hatalar ekiplerin tutarlılık davranışını varsaymasıyla olur. Her özellik için "doğru"nun ne olduğunu açıkça belirtin: kabul edilebilir gecikme, kullanıcıların bu gecikme sırasında ne görmesi gerektiği ve güncellemeler sıra dışı geldiğinde ne olacağı.
Sonra bunu ölçün. Gerçek replikasyon gecikmesini, güncel olmayan okumaları, çakışma oranlarını ve kullanıcıya görünen uyuşmazlıkları takip edin. İzleme, "muhtemelen iyi"yi kontrollü, test edilebilir bir karara dönüştürür.
Bunu pratik yapmak için, ürün özelliklerinizi tutarlılık ihtiyaçlarına göre eşleyin, seçimi belgeleyin ve koruyucu önlemler ekleyin:
Tutarlılık tek beden bir seçim değildir. Amaç, kullanıcılara güven veren bir sistemdir—mümkün olduğu yerde hızlı, mutlaka olması gerektiğinde katı.
Nihai tutarlılık, aynı verinin farklı kopyalarının bir güncellemeden sonra kısa bir süre farklı değerler gösterebileceği, ancak güncellemeler yayıldıktan sonra aynı son duruma doğru yakınsadıkları anlamına gelir.
Pratikte: bir ekranda değişiklik kaydedebilirsiniz ve başka bir ekranda kısa süre eski değer görünebilir; sonra eşleşir.
Veri genellikle kullanılabilirlik ve hız için sunucular/bölgeler arasında çoğaltılır. Güncellemelerin ağ üzerinden gidip farklı replikalara uygulanması gerekir.
Replikalar kusursuz senkron çalışmadığından, bir replikada yeni değer varken diğerinde eski değer kısa süre kalabilir.
“Nihai” sabit bir sayı değildir. Replikasyon gecikmesi, ağ gecikmesi, yük, yeniden denemeler ve kesintilere bağlıdır.
Pratik bir yaklaşım hedef belirlemektir, örneğin:
ve UX ile izlemeyi buna göre tasarlamak.
Güçlü tutarlılık “herkes şimdi aynı fikirde” demektir ve genellikle coğrafi koordinasyon gerektirir. Bu koordinasyon:
Birçok sistem, hızlı ve yanıt veren kalmak için kısa süreli uyumsuzluğu kabul eder.
Kullanıcıya görünen en yaygın belirtiler şunlardır:
İyi bir UX bu durumları bozukluktan çok normalmiş gibi hissettirir.
Kendi yazdığını okuma demek, bir şeyi değiştirdikten sonra bir sonraki görünümde kendi değişikliğinizi görmeniz gerektiği anlamına gelir; tüm sistem henüz yakalanmamış olsa bile.
Takımlar bunu genellikle şunlarla sağlar:
Yüksek hacimli ve düşük riskli, biraz gecikmenin zararlı olmadığı türev deneyimler nihai tutarlılık için iyi adaylardır, örneğin:
Ana fikir: kısa süreli tutarsızlıklar geri döndürülemez kararlara yol açmamalı.
Nihai tutarlılıktan kaçınılması gereken durumlar, geçici uyuşmazlığın geri döndürülemez zarara yol açabileceği yerlerdir:
Türev görünümler için (panolar, öneriler) nihai tutarlılık kullanılabilir; ancak kaynak gerçeklik için güçlü tutarlılık tercih edilir.
Çakışmalar, replikalar henüz anlaşmadan önce iki güncelleme olduğunda ortaya çıkar (ör. aynı alanı eşzamanlı düzenleme). Yaygın stratejiler:
Seçiminiz ne olursa olsun davranışı tahmin edilebilir kılın ve kullanıcıyı etkilediğinde görünür yapın.
Tekrar denemeler normaldir (zaman aşımı, yeniden bağlanma), bu yüzden eylemler tekrarlandığında güvenli olmalıdır.
Yaygın taktikler:
Böylece "tekrar dene" rutininin riskli değil güvenli olduğu bir model kurarsınız.
