CAP Theorem: למה אי אפשר לקבל הכול, ואיך זה משפיע על כל החלטת ארכיטקטורה מבוזרת

מאת צוות מדיה דיל · 01.09.2026 · טכנולוגיה · 6 דק׳

CAP Theorem מצוטט הרבה ומובן לעומק מעט. מה זה באמת אומר לבחור בין Consistency ל-Availability, ולמה PACELC מספר את החצי השני של הסיפור.

CAP Theorem מצוטט הרבה ומובן לעומק מעט. הטענה הפורמלית שלו צרה יותר ממה שרוב האנשים חושבים — והיא נוגעת ישירות לכל החלטה על מסד נתונים מבוזר, מ-DynamoDB ועד CockroachDB ועד הבחירה הפשוטה בין מסד נתונים יחיד לאשכול.

שלושת האותיות, במדויק

Consistency אומרת שכל קריאה מחזירה את הכתיבה העדכנית ביותר או שגיאה — לא נתון ישן. Availability אומרת שכל בקשה מקבלת תגובה (לא שגיאה), גם אם היא לא הכי עדכנית. Partition Tolerance אומרת שהמערכת ממשיכה לתפקד גם כשיש כשל תקשורת בין חלקי הרשת. המשפט קובע: כשיש Partition בפועל, חייבים לבחור בין C ל-A — אי אפשר את שתיהן, כי כדי להבטיח שהתשובה עדכנית לחלוטין חייבים לחכות לאישור מהצד שאיתו אין כרגע קשר, וזה בדיוק מה שפוגע בזמינות.

Partition Tolerance היא לא באמת אופציה

הטעות הנפוצה היא לחשוב ש-CAP מציע לבחור 2 מתוך 3. בפועל, ברשת מבוזרת אמיתית, כשלי רשת יקרו — השאלה היא לא "אם" אלא "מתי". לכן P הוא לא בחירה אלא עובדה נתונה, וההחלטה האמיתית שכל צוות מקבל היא בין CP ל-AP בזמן שיש כשל רשת בפועל.

מערכות CP: עקביות על חשבון זמינות

מערכת CP (כמו etcd, או Postgres סינכרוני עם רפליקה) תעדיף להחזיר שגיאה או להיתקע על פני החזרת נתון לא עדכני. מתאים למקומות שבהם נתון שגוי גרוע יותר מהיעדר תשובה — יתרות בנקאיות, נעילות הפצה (Leader Election), מלאי בזמן צ'קאאוט.

מערכות AP: זמינות על חשבון עקביות מיידית

מערכת AP (כמו Cassandra או DynamoDB בברירת מחדל) תמשיך לענות גם כשיש Partition, גם במחיר שהתשובה עשויה להיות מעט לא מעודכנת — ותתעדכן בהמשך (Eventual Consistency). מתאים לפידים חברתיים, ספירת לייקים, המלצות — מקומות שבהם עדכניות של שנייה או שתיים לא קריטית.

רוב המערכות בפועל: PACELC, לא רק CAP

הרחבת PACELC מוסיפה נדבך חשוב: גם כשאין Partition בכלל, יש עדיין Trade-off בין Latency ל-Consistency — כי אישור סינכרוני מכל הרפליקות לוקח זמן. זו הסיבה שבחירת מסד נתונים לא מסתכמת ב"CP או AP" חד-פעמי אלא בכיוונון עדין של רמת עקביות מול זמן תגובה, לרוב per-query.

איך זה נוגע לשירוד (Sharding) בפועל

כשמחליטים על Database Sharding, שאלת CAP חוזרת בצורה קונקרטית: מה קורה כשצומת אחד מהקלאסטר לא זמין רגעית — האם המערכת חוסמת כתיבות לשארד הזה (CP) או ממשיכה עם עקביות רופפת יותר (AP)? זו לא שאלה תיאורטית אלא פרמטר תצורה ממשי בכל מסד מבוזר מודרני.

עקביות ברמת השירות, לא רק ברמת המסד

גם כשמסד הנתונים עצמו CP חזק, שכבות מעליו כמו Cache או Read Replicas מכניסות מחדש Eventual Consistency דרך הדלת האחורית. חשוב לחשוב על עקביות כמאפיין קצה-לקצה של המערכת כולה, לא רק כתכונה של רכיב בודד.

המסקנה המעשית לצוותי הנדסה

CAP לא אומר לכם איזה מסד נתונים לבחור — הוא אומר לכם לשאול "מה קורה במקרה של כשל רשת חלקי" לפני שקורה בפרודקשן, לא אחרי. הרוב המכריע של המערכות בפועל משלבות רמות עקביות שונות לרכיבים שונים, לפי מה שהעסק באמת דורש מכל נתון — יתרת חשבון דורשת CP קפדני, בעוד מונה צפיות בדף מוצר יכול בהחלט לחיות עם AP ושניות בודדות של פיגור.

בונים מערכת מבוזרת וצריכים לחשוב נכון על עקביות מול זמינות? דברו איתנו בוואטסאפ.

תגיות: CAP Theorem · Distributed Systems · Database Consistency · PACELC

← חזרה לבלוג · צור קשר