Uma negociação acontece uma vez. Quando chega a um banco de dados, ela traz três ou quatro horários diferentes, nenhum deles errado, e cada um mede algo ligeiramente distinto. A maioria das discussões sobre reconciliação, na verdade, trata de qual relógio alguém quis dizer.
Os relógios em um fluxo normal
| Timestamp | Definido por | Diferença típica em relação ao anterior |
|---|---|---|
| Horário do motor de matching | A bolsa, no momento do matching | Ponto de referência |
| Horário de publicação do feed | A camada de distribuição da bolsa | 10 a 500 microssegundos |
| Horário de recebimento no gateway | Seu broker ou fornecedor | 1 a 50ms em redes públicas |
| Horário de recebimento local | Seu próprio processo | 0.1 a 20ms, mais jitter de agendamento |
| Horário de gravação no banco de dados | Sua camada de armazenamento | Qualquer valor, e não é um evento de mercado |
A última linha é a que causa problemas, porque é a mais fácil de registrar e a menos significativa. Ordenar eventos pelo horário de gravação no banco de dados produz uma sequência que geralmente está certa e, às vezes, sob carga, está muito errada.
De onde vem a divergência
- Relógios diferentes. A bolsa, o gateway e seu host mantêm cada um o seu próprio relógio, sincronizados segundo padrões variados.
- Eventos diferentes. Matching, publicação, recebimento e armazenamento são quatro momentos distintos, não quatro leituras de um só.
- Resoluções diferentes. Um feed em milissegundos e um log em microssegundos nunca vão coincidir exatamente, e o arredondamento esconde o sentido do erro.
- Horário de verão e convenções da bolsa. Menos comuns do que antes, mas ainda não desapareceram, e sempre são descobertos no dia em que os relógios mudam.
O que fazer
- Armazene todos os timestamps que receber, cada um em sua própria coluna, em UTC.
- Registre seu próprio horário de recebimento com uma fonte monotônica, não com o relógio de parede.
- Monitore a diferença entre seu host e uma referência e configure alertas para desvios, em vez de verificar isso depois de um incidente.
- Escolha um relógio como chave de ordenação, registre essa decisão e faça com que cada relatório informe qual foi usado.
- Quando dois sistemas divergirem, compare o mesmo relógio em ambos antes de presumir que algum deles está com defeito.
O objetivo não é fazer os relógios coincidirem, porque eles medem coisas diferentes e nunca vão coincidir. É saber de qual relógio veio cada número, para que uma discrepância seja um fato sobre o fluxo, e não um mistério sobre os dados.
Perguntas frequentes
Qual timestamp devo armazenar?
Todos, em colunas separadas. Armazenar apenas um é uma decisão que não dá para desfazer, e o custo de três colunas bigint é insignificante perto do custo de reconstruir o histórico porque você manteve o relógio errado.
Qual costuma ser a diferença entre o horário da bolsa e o horário local?
Em uma conexão de varejo pela internet pública, geralmente 20 a 150ms, com desvios ocasionais muito maiores. Em um ambiente co-localizado, cai para microssegundos. A variação importa mais que o número.
NTP é suficiente?
Para estratégias medidas em segundos, sim, geralmente com precisão de poucos milissegundos. Para qualquer coisa medida em microssegundos, você precisa de PTP e timestamping por hardware, e deve monitorar a diferença em vez de presumir que está tudo certo.
Plataformas · Software · Provedores · Mercados