פיתוח בורסת CEX: מנוע התאמה, אבטחה, תשתית

פיתוח קריפטובורסה: היכן נשברת הרצת הפקודות

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

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

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

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

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

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

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

מה נותנת הליבה המעובדת מחדש: השהיות, כשלים, השבתה

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

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

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

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

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

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

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

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

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

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

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

שלבי ההטמעה: ניתוח התכנית, הגדרה, בדיקה, מסירה

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

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

מה נשאר בידיכם: תכניות, מדיניויות, נהלים

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

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

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

מקרה בוחן: כיצד הבורסה הפסיקה לאבד פקודות בשעות שיא

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

נקודת הכשל

בשיא אבדו עד 5% מהפקודות, אישור העסקה נמתח משבריר שנייה לכמה שניות. צוואר הבקבוק לא היה החומרה, אלא משאב משותף שכל פעולת כתיבה המתינה לו; כשל במודול החישובים עצר את המסחר כולו. הפלטפורמה ירדה לזמינות מופחתת ל-30–40 דקות, וההרמה בוצעה ידנית.

מה שינו ומה התקבל

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

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

במה שונה ליבת התאמה עצמאית מליבה מוכנה?

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

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

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

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

ספקות טכניים: יציבות, ביקורת, העברת נתונים

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

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

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

מה ניתן לבדוק לפני תחילת העבודה?

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

מה עושים אם פגם מתגלה לאחר ההשקה?

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

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

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

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

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