Polling מול Event: מי שואל ומי מודיע

אחרי שהבנו ש-Event הוא הצהרה על עובדה, השלב הבא הוא להבין שאלה בסיסית יותר:

איך בכלל מגלים שמשהו קרה?

יש שתי גישות עקרוניות:

לשאול שוב ושוב, או שיגידו לך כשזה קורה.

אלה הם Polling ו-Event.

Polling: לשאול אם משהו השתנה

Polling הוא מודל שבו רכיב במערכת: בודק שוב ושוב אם יש שינוי.

לדוגמה:

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

הבדיקה מתבצעת:

• בפרקי זמן קבועים
• בלי קשר אם משהו באמת קרה

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

למה Polling בכלל קיים

Polling הוא פשוט, צפוי, וברור.

היתרונות שלו:

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

הרכיב שואל - ומקבל תשובה.

Event: שיגידו לי כשזה קורה

במודל Event-driven, התמונה מתהפכת.

הרכיב לא שואל. הוא מניח: “כשתהיה עובדה רלוונטית - יודיע לי עליה”.

במקום בדיקות חוזרות:

• נוצרת עובדה
• נוצר אירוע
• והאירוע מופץ למי שמקשיב

אז למה Event לא תמיד “יותר מהיר”

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

אבל Event חוסך בדיקות, לא זמן.

כדי שאירוע יגיע:

• הוא צריך להיווצר
• להישלח
• להיות מתווך
• ולהתקבל

כל שלב כזה מוסיף השהיה.

Polling שואל מוקדם. Event מגיב מאוחר יותר - אבל חכם יותר.

תגובתיות מול Latency

Polling בזבזני - אבל צפוי. Event יעיל - אבל מוסיף תיווך.

לכן ההבדל האמיתי אינו: מהיר מול איטי,

אלא:

Polling נותן תגובה צפויה בקצב קבוע. Event נותן תגובה מותנית שאין הבטחה שתתקבל, עם זמן הגעה משתנה.

זו בחירה בין: שליטה בזמן לבין חיסכון בעבודה.

המשל

דמיינו שני אנשים:

אחד: בודק כל דקה אם הדלת נפתחה.

השני: מבקש שיקראו לו כשזה קורה.

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

השורה התחתונה

Polling ו-Event אינם טובים או רעים. הם מייצגים פילוסופיות שונות:

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

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