Prediction Market WebSocket API: Reconstrua Livros ao Vivo com Segurança
Uma conexão de socket é fácil. Manter um livro correto por meio de sementes, deltas, reconexões e cadência específica do local é o trabalho de engenharia real.
Um cliente WebSocket de mercado de previsão precisa de um livro inicial completo, ordem de atualização determinística, carimbo de data/hora de origem e recebimento, tratamento de heartbeat e um caminho de recuperação após qualquer lacuna. O Polymarket pode ser capturado de atualizações CLOB orientadas a eventos; os dados do Kalshi podem chegar por um mecanismo de local diferente. Um frame downstream normalizado é útil apenas quando preserva essas diferenças de origem em vez de fingir que cada local tem o mesmo transporte.
O estado máquina mínimo correto
- Resolva os identificadores de mercado e resultado estáveis antes de assinar.
- Carregue ou receba uma semente de livro completa antes de aplicar alterações incrementais.
- Aplique atualizações na ordem de origem documentada e rejeite o estado desatualizado.
- Acompanhe o heartbeat ou o tempo do último message independentemente para cada conexão.
- Em uma lacuna de sequência ou reconexão incerta, descarte o livro local e reseed.
- Publique o tempo de origem, o tempo de recebimento e uma flag clara de snapshot versus delta downstream.
Snapshot e delta não são intercambiáveis
Um snapshot substitui o estado; um delta o muta. Tratar um como o outro produz um livro que pode parecer plausível, mantendo níveis excluídos ou descartando tamanho inalterado. Escreva testes explícitos para inserção de nível, substituição de tamanho, exclusão e rejeição de livro cruzado.
Os consumidores downstream não devem precisar adivinhar se receberam uma escada completa. Inclua um tipo de message ou sirva frames de livro completo normalizados quando a simplicidade valer a pena a largura de banda adicional.
Normalização com consciência do local
DepthFeed captura o Polymarket do stream CLOB e registra observações normalizadas. Os livros de esportes e criptomoedas do Kalshi seguem caminhos de coleta específicos do local, documentados, incluindo REST público adaptável, quando aplicável. O esquema downstream pode permanecer consistente, enquanto os metadados identificam como e quando cada fonte foi observada.
Para planos pagos, o WebSocket do DepthFeed serve canais de livro ao vivo normalizados com limites de conexão e assinatura específicos do plano. As consultas REST históricas usam a mesma forma de preço-tamanho, o que torna possível reutilizar a lógica de análise e preenchimento entre o monitoramento ao vivo e a reprodução.
Testes de falha de produção
| Falha | Comportamento esperado | Comportamento inseguro |
|---|---|---|
| Conexão cai | Reconectar, reseed, retomar do estado conhecido | Continuar mutando o livro local desatualizado |
| Atualização duplicada | Tratamento idempotente ou verificação de ordem de origem | Dobrar o tamanho de repouso |
| Atualização fora de ordem | Rejeitar ou reconstruir | Aplicar por ordem de chegada sem evidências |
| Consumidor lento | Backpressure, coalescing ou política de desconexão | Crescimento de memória ilimitado |
| Nenhuma atualização recente | Expor frescor por mercado | Reportar o último preço como ao vivo |
Key takeaways
- 01Uma semente completa deve existir antes que os deltas possam formar um livro confiável.
- 02A incerteza da reconexão deve acionar um reseed, não uma continuação otimista.
- 03O tempo de origem e o tempo de recebimento respondem a diferentes perguntas de latência.
- 04A normalização deve preservar os metadados de captura específicos do local.
- 05As APIs ao vivo e históricas mais seguras compartilham uma forma de escada explícita.
Uma conexão de socket é fácil. Manter um livro correto por meio de sementes, deltas, reconexões e cadência específica do local é o trabalho de engenharia real.
Começar grátis