Ordering - למה סדר הוא מותרות יקרות

אחרי שטיפלנו בעומס, תורים ודחייה, נראה שהמערכת סוף-סוף “מתייצבת”.

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

וכאן מתחיל המחיר האמיתי.

למה סדר מרגיש מובן מאליו

כבני אדם, אנחנו חושבים בסדר:

• קודם זה
• אחר כך זה
• ואז התוצאה

קל להשליך את זה גם על מערכות: אם שלחנו בקשה A לפני בקשה B - ברור ש-A צריכה להתבצע קודם.

אבל רשתות ומערכות מבוזרות אינן חוות את העולם כך.

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

במערכת אמיתית:

• Packets מגיעים בזמנים שונים
• בקשות עוברות נתיבים שונים
• רכיבים מגיבים בקצבים שונים

אין “שעון משותף”. אין נקודת מבט אחת שמגדירה סדר מוחלט.

כדי לייצר סדר - צריך לאכוף אותו.

ואכיפה עולה ביוקר.

המחיר של אכיפת סדר

שמירה על Ordering מחייבת:

• להמתין לבקשה איטית כדי לא לעקוף אותה
• לעכב עבודה גם כשיש משאבים פנויים
• לשמור State כדי לזכור מה “מחכה למי”

התוצאה:

• Latency גבוה יותר
• Throughput נמוך יותר
• וסקייל מוגבל

המערכת מקריבה מקביליות כדי לשמור על רצף.

Out-of-order processing - לא באג, אלא אסטרטגיה

עיבוד לא לפי סדר נראה לעיתים כמו בעיה.

אבל בפועל, זו אחת הדרכים החזקות ביותר:

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

Out-of-order processing אומר: מטפלים במה שמוכן עכשיו, ולא מחכים למה שנתקע.

זה ויתור על סדר - לטובת זמינות ויציבות.

מתי סדר באמת חשוב

לא כל מערכת יכולה לוותר על Ordering.

סדר חשוב כש:

• יש תלות ישירה בין פעולות
• שינוי מצב אחד חייב לקרות לפני אחר
• או כשמשמעות עסקית תלויה ברצף

אבל גם אז, חשוב לשאול: האם הסדר נדרש בכל מקום - או רק בנקודה מסוימת?

אכיפה מקומית זולה יותר מאכיפה גלובלית.

המשל

אפשר לחשוב על מטבח במסעדה.

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

אם המנות יוצאות כאשר כל מנה מוכנה - הקצב עולה, אבל צריך לוודא שלא שכחנו אף סועד בדרך.

הבחירה היא בין סדר מושלם לבין זרימה.

Ordering כבחירה מודעת

מערכת יציבה אינה מניחה סדר כברירת מחדל.

היא שואלת:

• איפה סדר באמת נדרש
• איפה אפשר לוותר עליו
• ומה המחיר של כל בחירה

סדר הוא לפעמים מותרות, לפעמים הכרח, אבל תמיד - יקר.

מבט קדימה

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

שכל פעולה תקרה פעם אחת בלבד.

בלי סדר:

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

הפחד כאן פשוט: שמשהו יקרה שוב - בלי שנשים לב.

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

כאן נכנס מושג קריטי נוסף, שמאפשר למערכות לחיות עם אי-ודאות:

Idempotency.

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