Prediction Market WebSocket API: Bezpieczne odtwarzanie księgi zleceń na żywo
Połączenie socket jest proste. Utrzymanie poprawnej księgi zleceń poprzez inicjalizacje, delty, ponowne połączenia i specyficzne dla platformy tempo to właściwa praca inżynierska.
Klient WebSocket rynku predykcji potrzebuje kompletnej początkowej księgi zleceń, deterministycznego porządku aktualizacji, znaczników czasu źródła i odbioru, obsługi heartbeat oraz ścieżki odzyskiwania po każdej luce. Dane Polymarket można przechwytywać z aktualizacji CLOB opartych na zdarzeniach; dane Kalshi mogą przychodzić przez inny mechanizm platformy. Znormalizowana ramka downstream jest użyteczna tylko wtedy, gdy zachowuje te różnice źródłowe, zamiast udawać, że każda platforma ma ten sam transport.
Minimalny poprawny automat stanowy
- Rozwiąż stabilne identyfikatory rynku i wyniku przed subskrypcją.
- Załaduj lub odbierz kompletną inicjalizację księgi zleceń przed zastosowaniem zmian przyrostowych.
- Zastosuj aktualizacje w udokumentowanym porządku źródła i odrzuć nieaktualny stan.
- Śledź heartbeat lub czas ostatniej wiadomości niezależnie dla każdego połączenia.
- W przypadku luki w sekwencji lub niepewnego ponownego połączenia, odrzuć lokalną księgę zleceń i ponownie zainicjalizuj.
- Publikuj czas źródła, czas odbioru i wyraźny flagę snapshot-versus-delta downstream.
Snapshot i delta nie są wzajemnie wymienialne
Snapshot zastępuje stan; delta go modyfikuje. Traktowanie jednego jako drugiego powoduje powstanie księgi zleceń, która może wyglądać wiarygodnie, zachowując jednocześnie usunięte poziomy lub pomijając niezmieniony rozmiar. Napisz wyraźne testy dla wstawiania poziomów, zastępowania rozmiaru, usuwania i odrzucania krzyżowej księgi zleceń.
Konsumenci downstream nie powinni musieć zgadywać, czy otrzymali kompletną drabinę. Dołącz typ wiadomości lub serwuj znormalizowane ramki kompletnej księgi zleceń, gdy prostota jest warta dodatkowej przepustowości.
Normalizacja uwzględniająca platformę
DepthFeed przechwytuje Polymarket z strumienia CLOB i rejestruje znormalizowane obserwacje. Księgi zleceń sportowych i kryptowalut Kalshi podążają udokumentowanymi ścieżkami zbierania specyficznymi dla platformy, w tym adaptacyjnym publicznym REST, jeśli dotyczy. Schemat downstream może pozostać spójny, a metadane identyfikują, jak i kiedy każde źródło zostało zaobserwowane.
W przypadku płatnych planów, WebSocket DepthFeed obsługuje znormalizowane kanały księgi zleceń na żywo z limitami połączeń i subskrypcji specyficznymi dla planu. Historyczne zapytania REST używają tego samego kształtu cena-rozmiar, co umożliwia ponowne wykorzystanie logiki parsowania i wypełniania w monitorowaniu na żywo i odtwarzaniu.
Testy awaryjne w produkcji
| Awaria | Oczekiwane zachowanie | Niebezpieczne zachowanie |
|---|---|---|
| Utrata połączenia | Ponowne połączenie, ponowna inicjalizacja, wznowienie z znanego stanu | Kontynuacja mutacji nieaktualnej lokalnej księgi zleceń |
| Duplikat aktualizacji | Idempotentna obsługa lub sprawdzenie porządku źródła | Podwojenie spoczywającego rozmiaru |
| Aktualizacja spoza kolejności | Odrzucenie lub przebudowa | Zastosowanie w kolejności przybycia bez dowodu |
| Wolny konsument | Backpressure, łączenie lub polityka odłączenia | Nieograniczony wzrost pamięci |
| Brak niedawnej aktualizacji | Ujawnij świeżość według rynku | Zgłoś ostatnią cenę jako aktualną |
Key takeaways
- 01Kompletna inicjalizacja musi istnieć, zanim delty mogą utworzyć wiarygodną księgę zleceń.
- 02Niepewność ponownego połączenia powinna wywołać ponowną inicjalizację, a nie optymistyczną kontynuację.
- 03Czas źródła i czas odbioru odpowiadają na różne pytania dotyczące opóźnień.
- 04Normalizacja powinna zachować metadane przechwytywania specyficzne dla platformy.
- 05Najbezpieczniejsze API na żywo i historyczne dzielą jeden wyraźny kształt drabiny.
Połączenie socket jest proste. Utrzymanie poprawnej księgi zleceń poprzez inicjalizacje, delty, ponowne połączenia i specyficzne dla platformy tempo to właściwa praca inżynierska.
Zacznij za darmo