Como projetar dados de mercado cripto que continuam confiáveis quando a API falha

Uma API de preços pode responder com 200 OK e, ainda assim, entregar dados inadequados para uma decisão operacional. O preço pode estar atrasado, o volume pode usar outra moeda de referência, o ativo pode ter sido associado ao símbolo errado ou a fonte pode estar repetindo o último valor conhecido sem informar isso.

Por essa razão, um serviço confiável de dados cripto não deve ser projetado apenas para “buscar um preço”. Ele precisa responder a uma pergunta mais completa: qual é o valor, de onde veio, quando foi observado, como foi transformado e quanta confiança existe nele agora?

Este texto trata de engenharia de dados e resiliência de sistemas, não de recomendação financeira.

Comece definindo o contrato do dado

Antes de integrar provedores, defina o que cada campo significa. Um campo chamado price é ambíguo: preço da última negociação, preço médio, índice agregado ou ponto médio entre compra e venda?

O contrato interno deve especificar pelo menos:

• identificador canônico do ativo;
• moeda de cotação;
• tipo do preço;
• instante do evento no mercado;
• instante da coleta;
• fonte original;
• transformações aplicadas;
• política de expiração;
• estado de qualidade.

Essa distinção evita que consumidores interpretem como equivalentes valores produzidos por métodos diferentes.

Preserve timestamp e proveniência

Todo registro deveria carregar dois horários. observed_at representa quando a fonte observou ou produziu o dado. received_at indica quando seu sistema o recebeu. A diferença entre ambos ajuda a identificar latência, filas congestionadas e respostas antigas servidas por caches externos.

A proveniência também deve sobreviver à normalização. Guarde o nome do provedor, o endpoint ou canal utilizado e, quando possível, um identificador da resposta. Se o valor final for calculado a partir de várias fontes, registre quais participaram, quais foram descartadas e qual método de agregação foi usado.

Sem essa trilha, investigar um pico incorreto vira arqueologia: o número está no banco, mas ninguém consegue explicar como chegou lá.

Normalize sem apagar diferenças importantes

Provedores usam símbolos, precisão, pares e unidades diferentes. BTC, XBT e identificadores próprios podem representar o mesmo ativo, enquanto símbolos idênticos podem pertencer a projetos distintos. Portanto, não use apenas o ticker como chave. Mantenha um catálogo canônico baseado em identificadores estáveis e mapeamentos específicos por fonte.

A normalização deve tratar:

• moedas e unidades de cotação;
• casas decimais e regras de arredondamento;
• volumes por período;
• timezone dos timestamps;
• contratos em redes diferentes;
• valores ausentes ou representados como zero.

Zero não deve substituir ausência. Um preço realmente igual a zero, um campo não informado e uma falha de conversão são estados diferentes e precisam permanecer distinguíveis.

Detecte dados vencidos explicitamente

A validade depende do ativo e do caso de uso. Dez minutos podem ser aceitáveis em um relatório diário, mas não em uma interface que se apresenta como tempo real.

Defina um limite de frescor por categoria e calcule a idade usando observed_at, não apenas o momento da última gravação. Uma coleta recente pode conter uma observação antiga.

Estados simples facilitam o consumo:

• fresh: dentro do intervalo esperado;
• delayed: utilizável, mas acima da latência normal;
• stale: expirado para o caso de uso;
• unavailable: não há valor seguro para retornar.

Nunca renove artificialmente o timestamp de um valor em cache. Isso esconderia a idade real do dado.

Use múltiplas fontes com regras previsíveis

Fallback não significa escolher silenciosamente qualquer resposta disponível. Cada fonte pode ter cobertura, liquidez e metodologia distintas. Estabeleça uma ordem ou estratégia por ativo e documente quando a troca acontece.

Uma política possível é usar uma fonte primária enquanto ela estiver saudável, recorrer à secundária quando houver timeout ou dado vencido e comparar ambas durante a recuperação. Para ativos líquidos, uma mediana entre fontes elegíveis pode reduzir o impacto de um valor extremo. Para mercados pouco líquidos, agregar sem considerar volume e origem pode criar uma precisão ilusória.

Também é importante evitar alternância constante entre provedores. Use um período mínimo de estabilidade antes de promover novamente uma fonte que acabou de se recuperar.

Combine cache e circuit breaker

O cache reduz latência e protege contra limites de requisição, mas precisa preservar a idade do conteúdo. Uma resposta em cache deve incluir o timestamp original e seu estado atual.

Adote dois prazos: um TTL curto para operação normal e uma janela limitada de stale-if-error. Dentro da segunda janela, o sistema pode retornar o último valor conhecido, desde que o marque claramente como vencido. Depois dela, é mais seguro declarar indisponibilidade.

Um circuit breaker interrompe chamadas repetidas a um provedor que está falhando. Após um número definido de erros, o circuito abre, aguarda um intervalo e testa a recuperação com poucas requisições. Isso evita tempestades de retries e libera recursos para os fallbacks.

Retries devem ter limite, backoff exponencial e jitter. Repetir imediatamente a mesma chamada em centenas de processos costuma ampliar a falha.

Valide anomalias antes de publicar

Uma resposta tecnicamente válida pode conter um preço absurdo. Compare o novo valor com:

• a última observação confiável;
• outras fontes independentes;
• limites plausíveis de variação;
• volume e liquidez associados;
• comportamento recente do mesmo mercado.

Não descarte automaticamente toda mudança brusca: mercados cripto podem se mover rapidamente. Em vez disso, coloque a observação em quarentena, busque confirmação e reduza seu nível de confiança. Regras fixas funcionam melhor quando combinadas com referências dinâmicas, como desvio em relação à mediana recente.

Exponha qualidade junto com o preço

Consumidores não deveriam reconstruir a saúde do dado a partir de logs internos. A resposta pode incluir um estado, uma pontuação de confiança e razões legíveis por máquina.

{ "asset_id": "bitcoin", "quote": "USD", "price": "64231.18", "observed_at": "2026-09-19T10:42:11Z", "received_at": "2026-09-19T10:42:12Z", "source": "provider_b", "status": "delayed", "confidence": 0.82, "flags": ["PRIMARY_UNAVAILABLE", "FALLBACK_ACTIVE"], "age_seconds": 46}

A pontuação não deve ser decorativa. Documente quais fatores a alteram: idade, número de fontes concordantes, liquidez, anomalias e saúde do provedor. Para decisões automáticas, prefira também estados categóricos e flags, que são mais auditáveis do que um número isolado.

Checklist operacional

Antes de colocar o serviço em produção, verifique:

• métricas de latência, erros e idade por provedor;
• alertas para aumento de dados stale;
• limites de requisição conhecidos e monitorados;
• fallback testado com falhas simuladas;
• circuit breaker e retries com parâmetros explícitos;
• logs de proveniência sem dados secretos;
• catálogo de ativos versionado;
• testes para símbolos duplicados e mudanças de contrato;
• relógios sincronizados nos serviços;
• dashboards separados para disponibilidade e qualidade;
• procedimento para invalidar valores incorretos;
• comunicação clara aos consumidores durante incidentes.

Também faça exercícios periódicos desligando a fonte primária em ambiente controlado. Resiliência que nunca foi testada costuma existir apenas no diagrama.

Conclusão

Confiabilidade não significa prometer que um preço estará sempre disponível. Significa representar honestamente a condição do dado e degradar o serviço de forma controlada. Quando timestamps, proveniência, normalização, fallback e sinais de qualidade fazem parte do contrato, aplicações conseguem distinguir um valor atual de uma estimativa atrasada — e indisponibilidade deixa de ser confundida com certeza.

Mushegh Manukyan é Founder & CEO da ARMCP.net, plataforma de informação cripto e Web3 baseada em Yerevan. Seu trabalho se concentra em dados de mercado, ferramentas blockchain, desenvolvimento de startups e clareza regulatória.