דילוג לתוכן הראשי
 קייס סטאדיז
ניסיון מקצועי

תכנון ופיתוח Kafka Router לפלטפורמה בנקאית חדשה

תכנון ומימוש של שכבת ניתוב מרכזית לאירועי Kafka, עם טיפול בכשלים, מנגנוני Retry וניהול Dead Letter Queue.

מקור
UMTB Bank, Senior Backend & Platform Engineer
Tech Stack
Kafka · NestJS · Node.js · TypeScript · Testcontainers · Splunk
מערכות מבוזרות, ארכיטקטורת Event-Driven, Platform Engineering, אמינות,

אמל״ק

הבעיה
פלטפורמה בנקאית הייתה צריכה דרך אחת ועקבית לצרוך ולנתב אירועי Kafka ולטפל בכשלים, בלי שכל שירות יבנה מחדש לוגיקת Retry ו-Dead Letter Queue.
התרומה שלי
הייתי אחראי על הארכיטקטורה ועל המימוש של ה-router. חקרתי את התכנון באופן עצמאי ועדכנתי את ה-principal architect ואת ה-tech lead, וה-principal architect אימת בהמשך את התכנון שמומש.
תוצאה וראיות
ה-router מממש ניתוב לפי סוג שגיאה וניהול Dead Letter Queue לזרימות אירועי Kafka בנקאיות, ונבדק בבדיקות אינטגרציה מבוססות Testcontainers. לא נמדדו נתוני latency, תפוקה או זמינות.
להעמקה בפרטים הטכניים

הבעיה

הפלטפורמה הבנקאית של בנק מזרחי-טפחות (UMTB) הייתה צריכה דרך אחת ועקבית לשירותי Backend לצרוך ולנתב אירועי Kafka, ולטפל בכשלים באופן צפוי. המטרה הייתה שכל שירות לא יצטרך לבנות מחדש לוגיקת Retry ו-Dead Letter Queue משלו.

הקשר

הפלטפורמה נבנתה מאפס (greenfield): מערכת בנקאית חדשה, בלי מוסכמות קיימות שאפשר היה להסתמך עליהן. עבדתי על התשתית המשותפת של הפלטפורמה והייתי אחראי על התכנון של ה-Kafka router.

אילוצים

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

התפקיד שלי

הייתי אחראי על הארכיטקטורה ועל המימוש של ה-Kafka router. חקרתי את התכנון בעצמי וקיבלתי בעצמי את ההחלטות המרכזיות.

לצד זה עדכנתי באופן שוטף את ה-principal architect ואת ה-tech lead בזמן שהתכנון התגבש. זה היה מעגל משוב מתמשך ולא סקירה חד-פעמית, והוא עזר לי לזהות פערים מוקדם ולבדוק את התכנון מול הארכיטקטורה הרחבה של הפלטפורמה. ה-principal architect אימת בהמשך את התכנון שמומש.

ארכיטקטורה וגישה

ה-router יושב בין ה-topics הגולמיים של Kafka לבין השירותים שצורכים אותם. הוא מסווג כל כשל לפי סוג השגיאה ומנתב אותו. החלטות ה-Retry תלויות בסטטוס התגובה של שירות ה-downstream, כולל 500, 503 ו-504. כל סוג שגיאה מנותב ל-Retry מיידי, ל-Retry מושהה (מדורג) או ל-Dead Letter Queue.

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

החלטות מרכזיות

  • ניתוב לפי סוג שגיאה במקום Retry אחד לכולם. כשלים שונים דורשים טיפול שונה. ה-router מסווג תחילה את הכשל, ואז מחליט בין Retry מיידי, Retry מושהה ו-Dead Letter Queue.
  • router מרכזי אחד במקום ספרייה בכל שירות. רכיב אחד מספק מקום אחד לתקן בו באגים ומקום אחד לזהות בו דפוסי כשל. עותקים עצמאיים בכל שירות היו מתרחקים זה מזה עם הזמן.
  • תיאום שוטף במקום סקירת תכנון חד-פעמית. שיתפתי את הגישה צעד אחר צעד עם ה-principal architect ועם ה-tech lead, כך שאי-התאמות התגלו בשלב שבו עוד היה קל יחסית לתקן אותן.

שיקולים ופשרות

אחריות עצמאית על התכנון אפשרה לי להתקדם מהר יותר מאשר בתהליך החלטות קבוצתי. מנגד, הייתי צריך לזהות בעצמי חולשות בתכנון שלי. התיאום השוטף עם ה-principal architect ועם ה-tech lead סיפק לכך מענה, בלי שער אישור פורמלי.

בנוסף, router מרכזי הוא תלות משותפת: באג בו עלול להשפיע על הפלטפורמה כולה. לכן כיסוי הבדיקות היה חשוב לא פחות מלוגיקת הניתוב, והוא מומש בבדיקות אינטגרציה מבוססות Testcontainers. חקרתי ותיקנתי בעצמי כשל קריטי ב-Testcontainers של Kafka, בלי צורך להסלים אותו לגורם נוסף.

תוצאות ואימות

ה-router מנתב זרימות אירועי Kafka בנקאיות באמצעות ניתוב אוטומטי לפי סוג שגיאה וניהול Dead Letter Queue. הפלטפורמה שבה הוא פועל מטפלת במיליוני אירועים בחודש. זה נתון על היקף הפלטפורמה, ולא מדד ביצועים שמדדתי עבור ה-router.

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

לא נמדדו נתוני latency, תפוקה או זמינות עבור ה-router, ואין טענה לגביהם.

מה למדתי

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