מערך שיעור: Processing Service ו-DLQ

משך: 2.5 שעות אקדמיות (113 דקות).

מטרת השיעור: הסטודנטים יבנו Processing Service עם Dead Letter Queue, שירות שני בפרויקט הסיום.

בסוף השיעור הסטודנטים צריכים: לעבד הודעות עם Pandas, לכתוב ל-MongoDB, ולממש DLQ שמונע אובדן נתונים על כישלון.

דגש קריטי: DLQ הוא הרעיון המרכזי החדש בשיעור — קשרו אותו במפורש ל-try/catch ברמת מערכת, לא רק “עוד Topic”.

מהלך השיעור#

דגשים להעברת השיעור#

• ההדגמה הפותחת (Consumer שקורס על נתון פגום, בלי DLQ) חייבת להיות אמיתית — הריצו אותה בפועל, לא רק תארו.
• DLQ שווה קישור מפורש ל-try/catch/finally מיחידת היסודות — “זה בדיוק אותו רעיון, ברמת מערכת שלמה במקום שורת קוד בודדת”.
• ודאו שסטודנטים ממשיכים ללולאה אחרי טיפול בכישלון (continue implicit) — לא לתקוע את כל ה-Consumer על הודעה בודדת.

מושגים#

Processing — ניקוי וטרנספורמציה של נתונים גולמיים. Dead Letter Queue (DLQ) — Topic נפרד להודעות כושלות. Load ל-MongoDB — שמירת תוצאה מעובדת ב-Document DB.

תרגיל חשיבה#

שאלת פתיחה: “בלי DLQ, מה קורה כש-Consumer שלכם נתקל בהודעה פגומה שגורמת לחריגה בלתי-מטופלת? האם שאר ההודעות ב-Topic עדיין מעובדות?”

מהלך: הובילו לתובנה: בלי טיפול, חריגה בלתי-מטופלת עלולה להפיל את כל תהליך ה-Consumer — כל שאר ההודעות (התקינות!) נתקעות ולא מעובדות עד שמישהו מפעיל את השירות מחדש. זה נזק גדול הרבה יותר מ"הודעה אחת אבודה" — כל הצנרת נעצרת.

מה המרצה מראה בסוף: הריצו Consumer עם הודעה פגומה מכוונת בשידור חי — פעם בלי try/except (הCurrent process קורס, הודעות תקינות אחריה לא מעובדות עד הפעלה מחדש), ופעם עם DLQ מלא (ההודעה הפגומה “יוצאת הצידה”, וכל השאר ממשיכות להתעבד כרגיל ברצף).