הודעה אחת, מיליוני פעמים בשנייה

ב-2023, CME Group דיווחה שהיא מעבדת בממוצע 23 מיליון הודעות ביום — ובבימי שיא (כמו תחילת החודש) יכול להגיע ל-120 מיליון הודעות ביום. כל הודעה כזו — פקודת קנייה, פקודת מכירה, ביטול, שינוי — צריך לעבור ולידציה, להיכנס ל-order book, ואם יש match — ליצור עסקה ולשלוח אישור. הכל תוך 50-100 מיקרו-שניות.

זו לא בעיה שאפשר לפתור עם REST API סטנדרטי ומסד נתונים רלציוני. בורסות מודרניות בנויות על ארכיטקטורות event-driven שבהן כל פעולה היא event, וכל event זורם דרך pipeline של processors שעובדים בזמן אמת.

מקרה אמיתי: LSEG (London Stock Exchange Group)

ב-2022, LSEG השלימה את העברת המערכת המסחר שלה למערכת event-driven מבוססת Aeron ו-Real Logic. התוצאה: latency ירד מ-200 מיקרו-שניות ל-30 מיקרו-שניות, throughput עלה פי 5, וסך העלות התפעולית ירדה ב-40%. למרות ההשקעה הראשונית הגדולה ($150 מיליון, החברה צופה שההשקעה תחזור בתוך 3 שנים.

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

פרוטוקולי התקשורת: FIX, FAST, ו-SBE

FIX (Financial Information eXchange) הוא הפרוטוקול הוותיק ביותר שעדיין בשימוש נרחב. הוא מבוסס טקסט (tag=value), אנושי-קריא, ונתמך על ידי כמעט כל בורסה בעולם. הבעיה? פענוח הודעת FIX דורש parsing של טקסט, וזה איטי.

FAST: דחיסה בינארית

פרוטוקול FAST (FIX Adapted for Streaming) נועד לפתור את בעיית הביצועים של FIX. הוא משתמש בקידוד בינארי, דחיסה של שדות חוזרים (delta encoding), ומבנה הודעה קבוע מראש. התוצאה: הודעות קטנות יותר ב-60-80% ופיענוח מהיר פי 5-10.

SBE: מהירות על חשבון גמישות

SBE (Simple Binary Encoding) הוא הפרוטוקול ש-CME בחרה עבור iLink 3.0. הוא מגדיר מבנה בינארי קבוע — אין parsing, אין הקצאת זיכרון דינמית, אין garbage collection. הודעת SBE היא פשוט struct בזיכרון. היתרון: latency דטרמיניסטי ברמת הננו-שניות. החיסרון: כל שינוי בפרוטוקול דורש קומפילציה מחדש.

Apache Kafka בתשתיות מסחר

Kafka היא לא "message queue" רגילה. היא distributed log שמאפשרת replay, retention, ומספר צרכנים שקוראים באותו קצב או בקצב שונה. בתשתיות מסחר, Kafka משמשת כ-backbone של ה-data pipeline — אבל לא ב-critical path של ה-matching engine.

הסיבה: Kafka (אפילו עם linger.ms=0) מוסיפה latency של 1-5 מילישניות. ב-matching engine שצריך להגיב תוך מיקרו-שניות, זה יותר מדי. אז Kafka משמשת downstream — לקליטת market data, audit trail, וניתוחים בזמן אמת.

ארכיטקטורה טיפוסית

בבורסה מודרנית, זרימת הנתונים נראית בערך ככה:

1. פקודת מסחר נכנסת דרך order gateway (SBE/FIX) ישירות ל-matching engine
2. ה-matching engine מעבד ומחזיר תגובה — בלי תיווך של Kafka
3. במקביל, event של העסקה נכתב ל-Kafka topic
4. צרכנים שונים קוראים מה-topic: market data disseminator, risk engine, audit log, analytics
5. Apache Flink (או מעבד stream אחר) מבצע אגרגציות ו-alerting בזמן אמת

Apache Flink: עיבוד stream בזמן אמת

Apache Flink הוא stream processing framework CNCF-graduated שעובד לפי מודל event-at-a-time (בניגוד ל-micro-batch של Spark Streaming). בתשתיות מסחריות, Flink משמש למשימות כמו:

• זיהוי אנומליות בזמן אמת — למשל, פקודה חריגה בגודלה או בתדירותה
• חישוב VWAP (Volume Weighted Average Price) על פני חלון זמן נע
• אגרגציה של market data מבורסות מרובות
• ניטור risk exposure של סוחרים בזמן אמת

היתרון של Flink על פני alternatives כמו Kafka Streams הוא היכולת לנהל state מורכב (keyed state, operator state) עם exactly-once semantics. כשעוסקים בנתונים פיננסיים, "בערך" לא מספיק — כל event צריך להיות מעובד בדיוק פעם אחת.

DataStream<TradeEvent> trades = env.addSource(new TradeSource());

trades
    .keyBy(TradeEvent::getSymbol)
    .window(TumblingEventTimeWindows.of(Time.seconds(60)))
    .aggregate(new VWAPAggregator())
    .addSink(new MarketDataSink());

Flink עם SQL

Flink יש גם Table API ו-Flink SQL — ממשק SQL שמאפשר לכתוב שאילתות על streams בדיוק כמו על טבלאות רגילות. זה מאוד שימושי לסוחרים ומומחים בסיכון שאינם מפתחים Java/Scala — הם יכולים לכתוב שאילתות כמו:

SELECT symbol, 
       AVG(price * volume) / SUM(volume) as vwap
FROM trades
GROUP BY TUMBLE(ts, INTERVAL '1' MINUTE), symbol

Eurex T7 מול CME iLink 3.0

שתי הפלטפורמות המובילות בתעשייה מייצגות גישות שונות לאותה בעיה.

Eurex T7

פלטפורמת T7 של Eurex (חלק מ-Deutsche Börse) בנויה על Java ו-C++. היא תומכת במגוון פרוטוקולים — FIX, FAST, ו-proprietary binary. הגישה: גמישות מעל הכל. T7 מאפשרת למשתתפים לבחור את הפרוטוקול שמתאים להם, ומספקת API עשיר לניהול risk.

ה-matching engine של T7 עובד ב-latency של 3-5 מיקרו-שניות (p99). זה מהיר, אבל לא הכי מהיר בתעשייה. הבחירה ב-Java מאפשרת פיתוח מהיר ותחזוקה נוחה, אבל מוסיפה overhead של garbage collection — ש-T7 מטפלת בו באמצעות tuning אגרסיבי ו-allocation-free code paths.

CME iLink 3.0

CME הלכה בכיוון ההפוך: raw speed על חשבון גמישות. iLink 3.0 משתמש ב-SBE בלבד, עם FPGA acceleration ל-matching engine. ה-latency: מתחת ל-1 מיקרו-שנייה במקרים מסוימים.

ה-trade-off: כל שינוי בפרוטוקול דורש עדכון firmware ב-FPGA. זה אומר ש-CME צריכה לתכנן שינויים חודשים קדימה, בעוד T7 יכולה לעדכן קוד Java ולפרוס תוך ימים. עבור high-frequency traders, ה-latency שווה את זה. עבור מי שסוחר פעם ביום — זה לא משנה.

נקודה למחשבה: ה-latency הנמוך ביותר בתעשייה שייך לבורסות שעושות colocation — הן מאפשרות ל-HFT firms למקם את השרתים שלהם פיזית ליד ה-matching engine. במצב כזה, ה-latency של הרשת הוא פחות מ-1 מיקרו-שנייה, וה-botleneck הופך להיות זמן העיבוד של ה-FPGA עצמו.

FPGA ב-matching: למה חומרה ולא תוכנה

FPGA (Field-Programmable Gate Array) הוא שבב שניתן לתכנת ברמת הלוגיקה הדיגיטלית. בניגוד ל-CPU שמריץ instructions ברצף, FPGA מבצע פעולות במקביל ברמת החומרה.

ב-matching engine, זה אומר: במקום לרוץ על לולאה של "קבל הודעה → פענח → חפש ב-order book → התאם → שלח תגובה", ה-FPGA מבצע את כל השלבים האלה ב-pipeline מקבילי. תוך שהודעה אחת מפוענחת, ההודעה הקודמת כבר מבוצעת match, וההודעה שלפניה כבר נשלחה.

החיסרון: פיתוח FPGA דורש מומחיות ב-Verilog או VHDL, cycle time ארוך, ודיבאג שהוא הרבה יותר קשה מתוכנה רגילה. לא כל ארגון יכול להרשות לעצמו את זה.

Aeron: messaging ללא פשרות

Aeron היא ספריית messaging שפותחה על ידי Real Logic (Martin Thompson) במיוחד עבור מערכות low-latency. היא משתמשת ב-memory-mapped files, zero-copy, ו-UDP multicast כדי להשיג latency של מאות ננו-שניות עם throughput של מיליוני הודעות בשנייה.

Aeron משמשת בכמה בורסות ו-HFT firms כתחליף ל-Kafka בצד ה-low-latency של ה-pipeline. היא לא מחליפה את Kafka — היא משלימה אותה. Aeron מטפלת בתקשורת ה-critical path, ו-Kafka מטפלת ב-data pipeline ה-downstream.

סיכום: איך בוחרים ארכיטקטורה

אין ארכיטקטורה "נכונה" אחת. הבחירה תלויה ב-latency requirements, בתקציב, ובצוות:

• אם אתם בונים HFT system עם דרישה ל-latency של ננו-שניות: FPGA + SBE + Aeron
• אם אתם בונים מערכת מסחר כללית עם latency של מיקרו-שניות: Java/C++ + FIX/FAST + Kafka + Flink
• אם אתם בונים analytics platform: Kafka + Flink + data lake

העיקרון המשותף: event-driven, append-only log, ו-separation בין ה-critical path ל-data pipeline.