Timeouts - ההחלטה הקשה ביותר בתקשורת

אחרי שוויתרנו על ההנחה שהרשת אמינה, מופיעה מיד ההחלטה הראשונה שאי אפשר להתחמק ממנה:

כמה זמן מחכים?

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

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

Timeout אינו מדידה - הוא ניחוש

אין מדד שמספר: “זה הזמן הנכון לחכות”.

Latency משתנה:

• בין בקשות
• בין עומסים
• בין רגעים ביום
• ובין רכיבים שונים בשרשרת

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

וגם אם ההימור היה נכון אתמול - אין שום הבטחה שהוא נכון עכשיו.

למה אין Timeout “נכון”

Timeout קצר מדי:

• חותך בקשות שעדיין היו מצליחות
• מייצר תחושת חוסר יציבות
• ומפעיל retries מוקדמים

Timeout ארוך מדי:

• מחזיק משאבים תפוסים
• מאריך תורים
• ומסתיר בעיות אמיתיות

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

ה-Timeout “הנכון” תלוי תמיד בהקשר - וההקשר משתנה.

Timeout, Latency ותורים - מעגל סגור

Timeout אינו פועל בוואקום.

ברגע שתור מתארך:

• Latency עולה
• יותר בקשות חוצות את ה-Timeout
• יותר בקשות נחתכות
• ויותר retries נשלחים

ה-Timeout לא מזהה בעיה - הוא מגיב אליה.

ובתגובה שלו, הוא לעיתים מחמיר אותה.

Timeout כטריגר לעומס משני

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

בקשה אחת שמתעכבת → Timeout → Retry → עוד בקשה → עוד עומס → עוד Timeout.

כך נולדות retry storms: לא בגלל שהמערכת לא עבדה, אלא בגלל שהיא עבדה לאט מדי.

ה-Timeout הפך ממנגנון הגנה למכפיל נזק.

המשל

אפשר לחשוב על טלפון שלא נענה.

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

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

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

Timeout הוא החלטה ערכית

מאחורי כל Timeout מסתתרת שאלה עמוקה יותר: על מה אנחנו מוכנים לוותר?

• על תגובתיות?
• על יציבות?
• על ניצול משאבים?
• על חוויית משתמש?

ה-Timeout קובע: מי סובל כשיש בעיה - השולח, המקבל, או כל המערכת.

זו לא החלטה טכנית. זו מדיניות.

סימן אזהרה חשוב

אם ה-Timeout נקבע כך:

• “כי ככה היה קודם”
• “כי זה נשמע סביר”
• או “כי זה עבד בבדיקות”

סביר מאוד שהוא מסוכן בפרודקשן.

Timeout בלי הקשר הוא מתכון לכשל מתגלגל.

מבט קדימה

ברגע ש-Timeout קיים, עולה השאלה הבלתי נמנעת:

אם חתכנו בקשה - האם מנסים שוב?

וכאן נכנס המנגנון שנראה תמים, אבל מסוגל להרוג מערכת שלמה:

Retries.

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