📌 تفاوت Strong Consistency و Eventual Consistency در یک نگاه

📌 تفاوت Strong Consistency و Eventual Consistency در یک نگاه


فرض کنین یه سیستم توزیع‌شده داریم با چندین node در مکان‌های مختلف (چیزی که مثلا این روزها با شرایط کم‌برقی لازمه). حالا وقتی یه داده تغییر می‌کنه، سوال اینه: کی و کجا اون تغییر رو ببینیم؟


🧱 Strong Consistency (سازگاری قوی)

هر تغییری که انجام بشه، همه باید فوراً ببینن. یعنی وقتی یه کاربر داده‌ای رو آپدیت کرد، تمام کاربران دقیقاً همون مقدار جدید رو ببینن — هیچ تأخیری در دیدن داده‌ی به‌روز وجود نداره.


✅ مناسب برای:


- سیستم‌های مالی یا رزرو که "دوگانگی" براشون قابل قبول نیست

- تراکنش‌های حیاتی مثل خرید سهام، پرداخت آنلاین


مثال ساده:

اگه از ATM پول برداریم، باید فوراً موجودی‌مون در همه جا بروز بشه. وگرنه ممکنه دوباره از یه دستگاه دیگه پول بکشیم!


🌊 Eventual Consistency (سازگاری نهایی)

داده ممکنه در لحظه همه جا یکی نباشه، ولی در نهایت (مثلاً چند ثانیه بعد) همسان می‌شه. این مدل performance بالاتری داره و مقیاس‌پذیرتره.


✅ مناسب برای:


- شبکه‌های اجتماعی

- سیستم‌های کش (Cache)

- فروشگاه‌های بزرگ آنلاین

- توزیع محتوا (CDN)


مثال ساده:

تو اینستاگرام یه پست رو لایک می‌کنی، ولی ممکنه چند ثانیه طول بکشه تا تعداد لایک برای بقیه آپدیت بشه — ولی در نهایت همه یه عدد می‌بینن.



💡 باید واقع‌بین بود، برخی موارد، تیم فنی این موضوع رو از یه آدم غیر فنی می‌پرسه که «قربان» دستور می‌فرمایید کدام گونه‌ی consistency را به خدمت گیریم؟! قربان هم پاسخ می‌ده: ببین مهندس «سامانه» ما خیلی مهمه، قراره میلیان‌ها بلکه میلیاردها کاربر در لحظه داشته باشه. فلذا داده‌ها باید در همه جا یکسان باشه، بلادرنگ، در لحظه! این می‌شه که آخرش نه توزیع‌یافتگی محقق می‌شه، وقتی هم محقق می‌شه با کندی و بدبختی و فلاکت برقرار می‌شه، اگر هم درست برقرار بشه، هزینه‌ی تمام‌شده معقولی نداره!

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