دو شعبه بانک، خط تلفن بینشان قطع میشود. مشتری در شعبه الف میخواهد پول بردارد. شعبه ب همان لحظه موجودی را نمیداند. دو راه داری: بگویی «الان نمیشود» تا موجودی دروغ نگویی، یا پول بدهی و بعداً حساب را جور کنی. قضیه CAP همین دوراهی است وقتی شبکه پاره میشود.
Partition انتخاب تو نیست؛ کابل قطع میشود، سوییچ میمیرد. هنگام Partition باید یکی را قربانی کنی: Consistency یا Availability. P اجباری است؛ انتخاب واقعی C در برابر A است.
سه حرف، سه شغل
CAP را مثل لغتنامه نخوان. بپرس در لحظه قطعی، سیستم چه قولی را نگه میدارد.
CP یا AP — با صحنه
برگرد به دو شعبه. اگر موجودی را دوبار بدهی، فاجعه است. اگر تعداد لایک دو ثانیه عقب باشد، کسی نمیمیرد. همین فرق، انتخاب را عوض میکند.
| انتخاب | رفتار هنگام قطعی | مثال درست |
|---|---|---|
| CP | بخشی از سیستم جواب نمیدهد، ولی هرگز جواب کهنه نمیدهد | موجودی بانک، صندلی باقیمانده، قفل توزیعشده |
| AP | همه جواب میگیرند، شاید چند ثانیه کهنه | تعداد لایک، فید، شمارنده بازدید، پروفایل |
طیف Consistency — فقط دو سر نیست
دنیا سیاهوسفید C یا A نیست. بین «همیشه تازه» و «بالاخره یکی میشوند» چند پله هست. برای UX معمولاً لازم نیست گرانترین پله را بخری.
در مدلهای Quorum — مثل Cassandra — با سه عدد بازی میکنی: N نسخه، W تأیید نوشتن، R نسخه برای خواندن. اگر W + R > N، خواندن و نوشتن حتماً همپوشانی دارند → Strong. مثلاً N=3 و W=2 و R=2. با W=1 و R=1 سریعترین و ضعیفترین.
به زبان ساده
وقتی خط بین دو شعبه قطع است، یا جواب نمیدهی تا دروغ نگویی، یا جواب کهنه میدهی تا باز بمانی.
مثال واقعی
برای لایک، چند ثانیه کهنگی بیضرر است؛ برای آخرین صندلی کنسرت بهتر است خطا بدهی تا دوبار نفروشی.