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

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

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

פרוטוקולי התקשורת: 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 בזמן אמת

Flink הוא stream processing framework שעובד לפי מודל 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());

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.