💡 باید واقع‌بین بود، برخی موارد، تیم فنی این موضوع رو از یه آدم غیر فنی می‌پرسه که «قربان» دستور می‌فرمایید کدام گونه‌ی consistency را به خدمت گیریم؟! قربان هم پاسخ می‌ده: ببین مهندس «سامانه» ما خیلی مهمه، قراره میلیان‌ها بلکه میلیاردها کاربر در لحظه داشته باشه. فلذا داده‌ها باید در همه جا یکسان باشه، بلادرنگ، در لحظه! این می‌شه که آخرش نه توزیع‌یافتگی محقق می‌شه، وقتی هم محقق می‌شه با کندی و بدبختی و فلاکت برقرار می‌شه، اگر هم درست برقرار بشه، هزینه‌ی تمام‌شده معقولی نداره!
مثال تجربی و واقعی: سال‌ها پیش (۱۳۸۷) همین چالش دشوار قانع کردن یک سازمان بزرگ برای غیرالزامی بودن strong consistency داشتم، از یک طرف مشکلات عدیده مقیاس‌پذیری و دسترس‌پذیری داشتن، از یه طرف اصرار مکرر بر اینکه ما کارمون حیاتیه و باید راهکار تضمین کنه که داده‌ها همه‌جا در لحظه یکسانه. با هزار اما و اگر، نهایتا راضی به تست شدند که ترکیبی از این دو رو پیاده کنم تا بخشی از سیستم، داده‌ها رو به لحظه داشته باشه، و بخش دیگه‌ای از سیستم بین ۴ تا ۱۰ ثانیه بعد توی ۳۷ نقطه در کشور داده‌ی به‌روز دریافت کنه. بعد از تست و دوره پایلوت، اون ساختار و معماری سال‌ها کار کرد (می‌کنه) و ثابت شد که «به‌روز» یک مفهوم مطلق و جهان‌شمول نیست. در حالیکه اگر قرار بود همه‌جا strong consistency بدم، تفریبا محال ممکن بود که کار انجام شه، یا اگر انجام میشد هزینه پیاده‌سازی و نگهداریش شاید بارها بیشتر بود، در حالیکه ۴ تا ۱۰ ثانیه برای اون نیاز، کاملا قابل قبول بود.