Eines Nachts habe ich an einem Hedging-Bot am Esstisch gearbeitet, und nach einer heftigen Erschütterung im Orderbuch haben die Logs ohne Unterbrechung angefangen zu feuern. Die Latenz sprang von 29 Millisekunden auf 121 Millisekunden in weniger als 3 Sekunden, aber ich konnte nicht sagen, ob die Engstelle bei der Edge-Berechnung lag, beim Order-Gateway oder im Markt-Datenstrom.
Diese Erfahrung hat mich genauer hinschauen lassen, wie GRVT Edge, Trades und Marktdaten in drei getrennte Gateways aufteilt. Das ist eine Änderung am Fundament der API, denn diese drei Abläufe unterscheiden sich in Last und Priorität. Sie zusammenzuhalten wirkt zwar bequem, aber das Isolieren von Fehlern wird dadurch sehr schwierig.
Es ist wie, wenn man Lebensmittelgeld, Notgroschen und Geld für Investitionen in demselben Konto führt. An einem normalen Tag wirkt das in Ordnung, aber sobald eine unerwartete Ausgabe auftaucht, wird die Abstimmung sofort chaotisch. APIs funktionieren ähnlich, und Marktdaten sind normalerweise der lauteste Teil—manchmal mit einer um den Faktor 6 höheren Nachrichtenmenge als bei den tatsächlich ausgeführten Orders.
GRVT behebt genau diesen Schmerzpunkt. Das Gateway für Marktdaten kann sich skalieren, um Peaks abzufedern, das Trades-Gateway kann die Ausführung gleichmäßiger halten, und das Edge-Gateway bleibt sauberer, weil es nicht durch die Feed-Queue mitgezogen wird. Wenn ein Spike 2 bis 5 Sekunden dauert, kann das Operations-Team sofort erkennen, ob die Engstelle eher bei den Daten oder bei der Ausführung liegt.
Das ist keine Allheilung, denn Rate Limits, Failover und Monitoring bestimmen weiterhin, wie sich das System in den Stoßzeiten verhält. Aber GRVT behebt einen Designfehler, mit dem viele Krypto-Infrastrukturen weiterleben: Das Mischen von Beobachtung, Entscheidungsfindung und Ausführung in derselben Leitung. An genau diesem Punkt zeigt GRVT, dass eine saubere Struktur ein echter Weg ist, Fehler zu reduzieren, wenn sich der Markt schnell bewegt. @grvt_io io #grvt
Diese Erfahrung hat mich genauer hinschauen lassen, wie GRVT Edge, Trades und Marktdaten in drei getrennte Gateways aufteilt. Das ist eine Änderung am Fundament der API, denn diese drei Abläufe unterscheiden sich in Last und Priorität. Sie zusammenzuhalten wirkt zwar bequem, aber das Isolieren von Fehlern wird dadurch sehr schwierig.
Es ist wie, wenn man Lebensmittelgeld, Notgroschen und Geld für Investitionen in demselben Konto führt. An einem normalen Tag wirkt das in Ordnung, aber sobald eine unerwartete Ausgabe auftaucht, wird die Abstimmung sofort chaotisch. APIs funktionieren ähnlich, und Marktdaten sind normalerweise der lauteste Teil—manchmal mit einer um den Faktor 6 höheren Nachrichtenmenge als bei den tatsächlich ausgeführten Orders.
GRVT behebt genau diesen Schmerzpunkt. Das Gateway für Marktdaten kann sich skalieren, um Peaks abzufedern, das Trades-Gateway kann die Ausführung gleichmäßiger halten, und das Edge-Gateway bleibt sauberer, weil es nicht durch die Feed-Queue mitgezogen wird. Wenn ein Spike 2 bis 5 Sekunden dauert, kann das Operations-Team sofort erkennen, ob die Engstelle eher bei den Daten oder bei der Ausführung liegt.
Das ist keine Allheilung, denn Rate Limits, Failover und Monitoring bestimmen weiterhin, wie sich das System in den Stoßzeiten verhält. Aber GRVT behebt einen Designfehler, mit dem viele Krypto-Infrastrukturen weiterleben: Das Mischen von Beobachtung, Entscheidungsfindung und Ausführung in derselben Leitung. An genau diesem Punkt zeigt GRVT, dass eine saubere Struktur ein echter Weg ist, Fehler zu reduzieren, wenn sich der Markt schnell bewegt. @grvt_io io #grvt