פיתוח פיד T&S לבורסות קריפטו מקצה לקצה

פיד Time & Sales: היכן הוא נשבר תחת עומס

פיד Time & Sales הוא זרם של כל העסקאות שהוצאו לפועל: מחיר, נפח, צד היוזם. בשוק רגוע הוא נראה תמים, אבל דווקא הוא הראשון שנתקל במגבלות התשתית בזרימת פקודות שיא, כאשר מודול ההרצה מפיק אירועים מהר יותר מאשר מצליחים להעביר ולצייר אותם.

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

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

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

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

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

אפקט ההטמעה: תגובה, שלמות, עמידות לשיאים

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

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

עמידות לשיאים נבדקת לא בעין, אלא בהרצת זרם מוקלט: השירות חייב לעבור פרץ בלי לאבד שורות ובלי עלייה בהשהיית הציור. אחרי ניתוק הפיד מדביק את הזרם בעצמו, בלי פעולות של תורן, — וזה בדיוק ההבדל שהלקוח רואה בתפעול.

פורמטי הפיד: זרם עסקאות, אגרגציה, תמונות מצב

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

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

תמונות מצב של היסטוריה סוגרות התחברות וניתוק ערוץ: הלקוח לוקח חתך לטווח הנדרש וממשיך מהמקום שבו עצר, בלי השמטות וכפילויות.

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

סדר העבודות: ביקורת זרם, סכימה, הרכבה, בדיקה

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

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

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

3. הרכבת השירות. מממשים מנוי, באפר, דה-דופליקציה והתחברות מחדש עם השלמת החלון החסר: ניתוק חיבור לא משאיר חור בפיד. את הפרסום מגדירים כך שההשהיה מהעסקה ועד הרשומה תישאר צפויה.

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

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

6. קבלת העבודות. מוסרים קונפיגורציות, סכימה, מדדים והוראות תפעול, ומפרקים עם הצוות שלכם תקלות אופייניות. בהמשך — ליווי: תיקונים לפי שינויים בפלטפורמות ובדיקת מקרים שנויים במחלוקת בהשוואה.

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

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

• ערכת תיעוד: תיאור טופולוגיית השירותים, פורמטי ההודעות והבטחות המסירה — כולל התנהגות בניתוק חיבור והתחברות מחדש עם טעינת עסקאות חסרות.
• סכימות אינטגרציה: דיאגרמות זרימה מליבת המסחר ועד למנויי הלקוח, נקודות חיבור, סדר ניתוב וכללי נרמול נתונים לפי כלים.
• נהל תפעול: סדר עבודות מתוכננות וחלונות תחזוקה, נוהל עליית גרסה חדשה וחזרה לקודמת, קריטריונים להסלמה מחייבת של תקלה.
• מדיניות הרשאות: תפקידים והרשאות בסביבות ייצור ובדיקה, הנפקה וביטול מפתחות, הפרדת גישה לליבת המסחר ולמאגר הנתונים ההיסטוריים.
• הוראות למשמרת תורן: תרחישים שלב-אחר-שלב לתקלות אופייניות — עלייה בהשהיית הפרסום, מפולת התחברויות מחדש, אי-התאמת הפיד עם הליבה, דעיכת ערוץ.
• ניטור והתראות: סט מדדים (שלמות הזרם, השהיה, שיעור ההודעות שנזרקו), ספי הפעלה ונמעני התראות.
• פרוטוקולי קבלה: תוצאות הרצות עומס ועמידות בכשלים בתוספת רשימת בדיקה אחרי כל מהדורה.

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

מקרה בוחן: זרם עסקאות שיא וזמן שחזור

בורסה עם פרצי פעילות חדים: רישומים, ליקווידציות מדורגות, פולסים חדשותיים. זרם העסקאות הממוצע בפיד Time & Sales עובר באופן יציב, אבל בשיא, היחס אליו גדל לעשרות מונים — ובדיוק בדקות האלה הפיד פיגר הכי הרבה, כשהנתונים נדרשים לפי שניות.

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

מה שינינו

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

תוצאה

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

במה שונה זרם עסקאות מספר הזמנות מאוגד?

זרם עסקאות, או פיד Time & Sales, הוא יומן הרצות: מחיר, נפח, זמן וצד היוזם בכל שורה. לפי תגית התוקף רואים אם הקונה לקח הזמנת לימיט למכירה או שהמוכר היכה בביד, — תמונת ספר ההזמנות לא מציגה דבר כזה.

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

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

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

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

שאלות טכניות ששואלים לפני תחילת העבודות

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

איך אתם מבטיחים סדר עסקאות נכון?

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

עד כמה מסובך להטמיע את זה בפלטפורמה שלנו?

אנחנו מתחברים כשירות נפרד לערוץ נתוני השוק שלכם ומוסרים זרם מנורמל לפי חוזה שסוכם עם הצוות שלכם; תאימות עם FIX ובפורמט הפנימי של הברוקר נבדקת בסטנד עד לשחרור. מודולי התאמה ומודולי יתרות לא משנים.

מה עם תמיכה אחרי העלאה לפרודקשן?

נשאר נהל: מדדי השהיה ושלמות הזרם, התראות על אי-התאמה מול מקור הבורסאי, תורנות וסדר ברור לחזרה לגרסה קודמת. הקבלה נעשית לפי סימנים — שיעור הניתוקים שנסגרו, השהיית הפרסום, היעדר כפילויות בחתך יומי.

נדון במשימה ונחזור עם הערכה ותוכנית

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

הבלוק השני — דרישות תפעול. צריך לדעת את פלטפורמות היעד (ווב, אפליקציות ניידות, מסוף שולחני), עומק ההיסטוריה הצפוי והשהיית העדכון המותרת, וכן תרחישי כשל: מה רואה המשתמש בניתוק ערוץ, בחוסר סנכרון ובהשמטת עסקאות.

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

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