Consistency מול Availability - לא תיאוריה, אלא בחירה יומיומית

אחרי שדיברנו על Timeouts, Retries, Backpressure, תורים, סדר ו-Idempotency, אפשר סוף-סוף לגעת במושג שרבים שמעו עליו - אבל מעטים באמת חיים אותו:

Consistency מול Availability.

לרוב הוא מופיע כסכמה תיאורטית. בפועל - זו החלטה שמתקבלת כל יום, גם כשלא קוראים לה בשם.

לא הכול יכול להיות גם זמין וגם עקבי

כשיש תקלה:

• רשת איטית
• רכיב שלא מגיב
• פיצול זמני בין חלקי מערכת

המערכת חייבת לבחור:

או: להחזיר תשובה מהר, גם אם היא לא לגמרי מדויקת

או: להמתין כדי להיות בטוחה, גם אם זה אומר עיכוב או כשל

אין אפשרות שלישית.

הבחירה הזו אינה תקלה - היא תוצאה של המציאות.

למה זו לא החלטה חד-פעמית

קל לחשוב: “המערכת שלנו היא כזו או כזו”.

אבל בפועל: הבחירה בין Consistency ל-Availability מתבצעת בכל נקודת קצה:

• האם להחזיר ערך ישן או שגיאה
• האם לאפשר פעולה חלקית
• האם להמשיך לעבוד כשלא הכול מסונכרן

מה המשתמש באמת מרגיש

מהנדסים מדברים על Consistency. משתמשים חווים אמון.

מערכת שזמינה תמיד אבל מחזירה נתונים מבלבלים:

• יוצרת חוסר ביטחון
• קשה להבין מה קרה
• והנזק מצטבר

מערכת שעקבית אך לא זמינה:

• מתסכלת
• אבל לרוב ברורה
• קל יותר להסביר את ההתנהגות שלה

בפועל, אין אסטרטגיה מועדפת תמיד. האסטרטגיה הנכונה היא זו המתאימה להקשר.

Consistency כעניין עסקי

הבחירה אינה טכנית בלבד.

שאלות כמו:

• האם מותר להציג מידע לא עדכני
• האם פעולה חלקית מותרת
• האם עדיף “בערך נכון” או “מדויק אבל מאוחר”

אלו שאלות עסקיות.

הטעות הנפוצה היא: להשאיר את ההחלטה הזו לברירת המחדל של המערכת.

ברירת מחדל היא גם החלטה - רק בלי אחריות ובלי הבנה.

Consistency ו-Availability אינם ערכים מוחלטים

מערכת יציבה אינה “בעד” אחד מהם.

היא שואלת:

• איפה חשוב להיות זמינים בכל מחיר
• איפה דיוק חשוב יותר
• ואיפה מותר להתפשר זמנית

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

מבט קדימה

עד עכשיו עסקנו בהחלטות בתוך מערכת אחת.

אבל מערכות מודרניות אינן לבד: הן מדברות עם אחרות.

בפוסט הבא נצא החוצה - ונבחן שלוש פילוסופיות תקשורת שונות: RPC, Messaging ו-Streaming, ולמה הבחירה היא בחירה עקרונית מהותית.