CAP

نظریه‌ی CAP که به اسم قضیه‌ی بروئر (Brewer’s Theorem) هم شناخته میشه، یه قانون پایه‌ای توی طراحی سیستم‌های توزیع‌شده‌ست.
میگه وقتی یه سیستم بین چند نود (node) پخش شده، در شرایط قطعی شبکه (partition)، نمی‌تونه به‌طور هم‌زمان سه ویژگی زیر رو تضمین کنه:

1. Consistency

2. **Availability **

3. **Partition Tolerance

این یعنی اگه شبکه‌ت قطع بشه، مجبوری بین Consistency و Availability یکی رو قربانی کنی.

1. Consistency

یعنی هر وقت یه کلاینت به سیستم درخواست بده، همه نودها یه داده‌ی یکسان نشون بدن.
فرقی نکنه به کدوم سرور وصل می‌شی، خروجی همیشه همونه.
مثلاً توی یه بانک، وقتی از حساب کم می‌کنی، باید همه‌ی سرورها فوراً همون موجودی جدید رو نشون بدن.

در عمل یعنی: بعد از هر write، تمام readها همون مقدار جدید رو ببینن.

2. Availability

یعنی سیستم همیشه جواب بده، حتی اگه بخشی ازش از کار افتاده.
در واقع هیچ درخواستی نباید timeout بشه یا خطای "سرویس در دسترس نیست" بده.

یعنی: هر نود باید همیشه بتونه یه پاسخ معتبر بده، حتی اگه داده قدیمی باشه.

3. Partition Tolerance

یعنی اگه یه بخش از سیستم با بخش دیگه نتونه ارتباط برقرار کنه (مثلا به خاطر قطعی شبکه یا latency زیاد)، سیستم هنوز بتونه کار کنه.

یعنی: سیستم باید بتونه در برابر split شدن شبکه بین نودها مقاومت کنه.

---

حالت های CAP:

در دنیای واقعی، Partition همیشه ممکنه — یعنی قطع ارتباط بین نودها یه واقعیت انکارناپذیره.
پس مجبور می‌شی بین دو گزینه‌ی باقی‌مونده یکی رو انتخاب کنی:

➤ CP: Consistency + Partition Tolerance

در این حالت، اگه شبکه قطع بشه و نودها نتونن باهم هماهنگ شن، سیستم دسترس‌پذیری رو فدا می‌کنه تا داده‌ها ناسازگار نشن.

مثلاً اگه نتونه داده رو replicate کنه، ترجیح می‌ده ارور بده تا داده‌ی قدیمی یا اشتباه برنگرده.

➤ AP: Availability + Partition Tolerance

در این مدل، سیستم همیشه پاسخ می‌ده، ولی ممکنه داده‌ها موقتاً ناسازگار بشن.

یعنی ممکنه یه کاربر موجودی حسابش رو ببینه که هنوز آپدیت نشده، ولی سیستم همچنان در حال کاره.

---

1. CAP همه‌چیز نیست

در عمل، سیستم‌های مدرن معمولا از مدل BASE (Basically Available, Soft state, Eventually consistent) استفاده می‌کنن که یه trade-off نرم‌تر از CAPه.

2. Consistency درجات مختلف داره

سیستم‌ها معمولاً بین حالت‌های مختلف consistency حرکت می‌کنن:

• Strong consistency → همیشه داده‌ی جدید

• Eventual consistency → در نهایت داده sync می‌شه

• Causal consistency → فقط آپدیت‌هایی که علت‌دار هستن باید مرتب دیده بشن