Queue אינו פתרון - הוא התחייבות
Queue אינו פתרון - הוא התחייבות
אחרי שדיברנו על Backpressure ועל היכולת לומר “לא עכשיו”, מגיע הכלי שנראה כמו פשרה נוחה:
נשים בתור.
לא דוחים, לא שוברים, רק… מחכים.
אבל כאן מסתתר אחד המיתוסים המסוכנים ביותר במערכות.
למה תור מרגיש כמו פתרון טוב
תור נותן תחושת שליטה:
- שום דבר לא הולך לאיבוד
- הכול “יטופל בהמשך”
- המערכת נשארת זמינה
על הנייר - מושלם.
אבל תור אינו מעלים בעיה. הוא דוחה אותה.
ודחייה היא התחייבות עתידית.
כל תור הוא הבטחה
ברגע שמכניסים בקשה לתור, המערכת אומרת:
אני מתחייבת לטפל בזה. לא עכשיו - אבל מתישהו.
זו הבטחה כבדה.
כי מרגע זה:
- הבקשה תופסת זיכרון
- היא תתחרה עם בקשות אחרות
- והיא תגדיל Latency עתידי
העומס לא נעלם. הוא פשוט נדחה.
Unbounded queues - חוב שלא רואים
תור בלי גבול נראה “בטוח”: הוא אף פעם לא מתמלא, אף פעם לא מחזיר שגיאה, ואף פעם לא מכריח החלטה.
וזו בדיוק הבעיה.
Unbounded queue:
- מאפשר לצבור עומס בלי לעצור
- מסתיר את חומרת המצב
- ודוחה את רגע האמת
עד שפתאום: Latency מתפוצץ, זמני תגובה הופכים לבלתי סבירים, והמערכת “עובדת” - אבל כבר לא שימושית.
זה לא פתרון. זה חוב שגדל בשקט.
Latency hiding לעומת Latency explosion
לעיתים תור באמת עוזר:
- הוא מחליק תנודות קטנות
- סופג bursts קצרים
- ומאפשר עבודה רציפה
זה Latency hiding.
אבל כשהעומס אינו רגעי - התור לא מחליק, הוא אוגר.
ואז מתרחש Latency explosion: כל בקשה חדשה משלמת לא רק על עצמה, אלא על כל מה שנצבר לפניה.
למה תורים שוברים חוויית משתמש
מנקודת מבט של המערכת, הכול עדיין “תקין”.
מנקודת מבט של המשתמש:
- התגובה איטית באופן לא צפוי
- זמני ההמתנה משתנים קיצונית
- ואין דרך להבין מה קורה
Latency גבוה ושגיאות ברורות - עדיפים על המתנה אינסופית.
המשל
אפשר לחשוב על מוקד שירות.
אם כל פנייה נכנסת לתור אינסופי: אף אחד לא מקבל “לא”.
אבל מי שמתקשר עכשיו עשוי להמתין שעה - בלי לדעת זאת מראש.
מוקד כזה לא נשבר טכנית - הוא פשוט מאבד אמון.
מתי תור הופך לחוב טכני
תור הופך לחוב כשהוא:
- מחליף החלטה בדחייה
- מסתיר עומס במקום לבלום אותו
- וגדל בלי גבול ברור
מערכת יציבה שואלת:
- כמה זמן מותר להמתין
- כמה בקשות מותר לצבור
- ומתי עדיף לוותר
תור טוב הוא תור עם גבול, עם מדיניות, ועם מחיר ידוע.
השורה התחתונה
Queue אינו פתרון לבעיה של קצב. הוא הסכמה לשלם עליה בעתיד.
אם לא ברור:
- מי משלם
- כמה
- ומתי
התור אינו מנגנון הנדסי - הוא הימור.
מבט קדימה
אחרי שהתמודדנו עם עומס, תורים ודחייה, אפשר לעבור לשאלה עמוקה יותר:
לא איך לעמוד בקצב - אלא איך לשמור על משמעות.
בחלק הבא נתחיל לדבר על סדר, עקביות, ולמה שמירה על Ordering היא אחת ההחלטות היקרות ביותר במערכת.
📚 פוסטים נוספים בסדרה: כשהתקשורת נשברת
- חלק 0 כשהתקשורת נשברת - הנדסה תחת עומס, כשל ואי-ודאות
- חלק 1 הנחת היסוד המסוכנת - הרשת אמינה "ברוב הזמן"
- חלק 2 Timeouts - ההחלטה הקשה ביותר בתקשורת
- חלק 3 Retries - מנגנון התאוששות או מכפיל נזק
- חלק 4 Load אינו אויב - Spikes כן
- חלק 5 Backpressure - כשלא אומרים "כן" לכול
- חלק 7 Ordering - למה סדר הוא מותרות יקרות
- חלק 8 Idempotency - לתכנן כאילו הכול יישלח פעמיים
- חלק 9 Consistency מול Availability - לא תיאוריה, אלא בחירה יומיומית
- חלק 10 RPC, Messaging, Streaming - שלוש פילוסופיות תקשורת
- חלק 11 Stateless זה לא שאין State - זה איפה הוא נמצא
- חלק 12 תקשורת כמשקפת תרבות הנדסית
- חלק 13 מערכות שמחזיקות - לא בגלל שהן חכמות, אלא בגלל שהן צנועות
- חלק 14 מה למדנו - מפת הדרך של הסדרה כולה