התמודדות עם CAP

יש כמה אפשרויות להתמודדות עם בעיות שמוצגות על ידי CAP.  הפשוטות הן:

ויתור על סבילות חלוקה
אם אתה רוצה לרוץ בלי מחיצות אתה צריך לעצור אותן מלקרות. דרך אחת לעשות זאת היא לשים הכל (כל מה שקשור ליחידה אחת או טרנזאקציה) במחשב אחד, או ביחידה אטומית אחת כמו מתלה (rack). זה לא  100% בטוח כי עדיין יכולים להופיע כשלים, אבל יש  פחות סיכוי לקבל תופעות לוואי שנובעות מחלוקה. לשיטה זו יש מגבלת גדילה משמעותיות.

ויתור על זמינות
זהו הצד השני של המטבע.כאשר יקרה אירוע שמתמשך מעבר למחיצה (או צומת) אחת, השירותים המושפעים פשוט ימתינו עד עדכון הנתונים. שליטה זו יכולה להיות מורכבת למדי על צמתים רבים.

ויתור על עקביות
או, לקבל כי הדברים כי יהפכו "בסופו של דבר לעקביים".  המון סתירות לא באמת דורשות הרבה עבודה כמו שניתן לחשוב (כלומר עקביות רציפה היא כנראה לא משהו שאנחנו צריכים ממילא). בדוגמת הספרים (מהפוסט הקודם) אם שתי הזמנות יכנסו לספר שקיים רק פעם אחת במלאי , הלקוח השני יקבל הודעת זיכוי על הקניה.

קפיצת בסיס (BASE Jump)
הרעיון של להיות עקבי בסופו של דבר נתמך באמצעות מה שנקרא BASE ו(Basically Available, Soft-state, Eventually consistent) ראשי התיבות קצת מאולצים אבל עדיין שימושים.

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