כשהתקשורת נשברת - הנדסה תחת עומס, כשל ואי-ודאות

למה להבין תקשורת זה לא מספיק

אם הגעתם לכאן, אתם כבר יודעים מה זה פרוטוקול, מה זה Packet, מה ההבדל בין TCP ל-UDP, ולמה Latency, תורים ו-HTTP נראים פשוטים רק מרחוק.

אתם כבר מבינים תקשורת.

אבל כאן מגיע השלב הפחות נוח: להבין - זה עדיין לא אומר לדעת לבנות מערכת שמחזיקה.

הידע שלא נשבר - וההנחות שכן

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

• שהרשת “בסדר בדרך כלל”
• ש-Timeout אחד טוב מתאים לכולם
• ש-Retry הוא תמיד רעיון טוב
• שאם זה עבד בעומס הקודם - זה יעבוד גם בבא

הידע נכון. ההקשר השתנה.

מה משתנה כשעוברים מרעיון למערכת חיה

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

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

מציאות שבה:

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

זו לא סדרה על מנגנונים - אלא על גבולות

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

נדבר על:

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

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

למה הסדרה הזו פחות מנחמת

כי היא לא מציעה מתכונים. היא מציעה אחריות.

אחרי הסדרה הזו:

• לא תוכלו להגיד “הרשת אשמה”
• תזהו Retry מסוכן גם כשהוא נראה חכם
• ותשאלו “מה יקרה תחת עומס?” לפני “כמה זה מהיר?”

זו אינה חשיבה פסימית. זו חשיבה בוגרת.

נקודת המוצא

ההנחה היחידה של הסדרה הזו היא:

כשל אינו אירוע חריג - הוא מצב פעולה.

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

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

מכאן והלאה, לא שואלים איך זה עובד - שואלים איך זה נשבר.