O Equity Tracker não prevê o mercado — lê 8 milhões de registros por dia

Preço de fechamento chega toda noite, em três praças com calendários que não coincidem: EUA, Brasil e cripto. Alguém precisa ler, cruzar e decidir o que vale olhar na manhã seguinte. Feito na mão, isso é uma planilha aberta todo dia útil, para sempre.

Montei o Equity Tracker sozinho justamente para não abrir essa planilha. Hoje ele está no ar com o nome Alpha Signal, processa mais de 8 milhões de registros por dia útil e devolve 12 flags de scoring por ativo. A pergunta que interessa não é se dá para prever o mercado. É se dá para virar esse volume em uma leitura consistente sem ninguém tocar em nada.

O problema nunca foi prever o mercado

Quem começa um sistema de dados financeiros costuma errar o alvo na primeira semana. Acha que o produto é previsão. Previsão é outro ofício, com outro conhecimento de domínio, e não era o que faltava aqui.

Faltava leitura. Todo dia útil, no fim do pregão, chega um bloco de preços de fechamento. Alguém passa o olho, compara com a véspera, separa o que mudou de comportamento do que só oscilou. Não exige inteligência. Exige repetição.

Repetição em três praças ao mesmo tempo é onde a coisa deixa de caber numa pessoa. EUA e Brasil não fecham no mesmo horário, e cripto não fecha. Manter a cobertura na mão significa três rotinas manuais em três janelas de tempo diferentes, todo dia, sem falhar uma vez. Ninguém sustenta isso por seis meses.

Quatro serviços sob Docker e um agendador que não pergunta nada

São quatro serviços em produção, todos sob Docker: banco, ETL, API e dashboard. Cada um sobe sozinho e cada um cai sozinho. Essa separação é a única razão pela qual dá para mexer no coletor sem derrubar o painel de quem está olhando.

O ETL é Python. Ele busca os dados de mercado, normaliza formato e grava no Supabase. O Supabase roda sobre Postgres e já traz autenticação e row-level security prontos; num Postgres nu, eu teria que escrever e manter as duas coisas antes da primeira linha de scoring. O acesso ao banco passa por SQLAlchemy.

Em cima do dado normalizado roda a engine de scoring: 12 flags compostas por ativo, montadas a partir de indicadores técnicos, volume e momentum. Não existe modelo de linguagem em nenhum ponto desse caminho. É aritmética determinística sobre dado de mercado. A mesma entrada produz a mesma flag hoje e daqui a um ano.

O frontend é Next.js, com widgets do TradingView nos gráficos, publicado em equity-tracker-ten.vercel.app. E existe um agendador que dispara doze tarefas por conta própria todo dia útil: coleta, normalização, cálculo, publicação. Esse doze não tem relação nenhuma com as 12 flags. É coincidência de número, e demorei a parar de misturar os dois quando explicava o sistema para alguém.

O que quebra num pipeline de mercado raramente é o cálculo

Pipeline de dados de mercado costuma falhar em três lugares, e nenhum deles é a conta do score.

O primeiro é fuso e calendário. Cada país tem feriado próprio, e a B3 fecha em dias que a bolsa americana ignora. Um coletor que confunde dia sem pregão com dia sem dado contamina a série inteira. O estrago só aparece semanas depois, quando o indicador de momentum começa a dar resultado estranho.

O segundo é limite de taxa do provedor. Puxar milhões de registros por dia útil significa bater no rate limit em algum momento, e o comportamento de um coletor que apanha do limite é calado: ele não quebra, ele traz menos.

O terceiro é normalização. A fonte muda o formato de um campo sem avisar, o parser aceita, o preço entra com escala errada. Nenhum dos três aparece como erro vermelho no log. Os três aparecem como número plausível.

O custo aqui é infraestrutura ligada, não chamada de modelo

A conta de um sistema desses não se parece com a conta de um produto de IA. Não existe chamada de modelo por requisição, porque o score é determinístico e sai de código Python sobre dado que já está no banco. O que pesa é o que fica ligado.

E o que fica ligado são os quatro serviços. Banco, ETL, API e dashboard rodam o tempo todo, porque o agendador precisa encontrar tudo de pé quando dispara as tarefas do dia. O frontend em Vercel é a parte barata. O resto é infraestrutura contínua, dimensionada para aguentar mais de 8 milhões de registros por dia útil sem acumular fila.

A troca é direta: você paga por disponibilidade em vez de pagar por uso. Se o painel ficasse ocioso metade do mês, a conta seria a mesma. Para um sistema que precisa estar atualizado toda manhã e opera com 99,9% de uptime, é a forma certa de gastar. Para um protótipo que roda uma vez por semana, seria desperdício.

Observabilidade do pipeline vem antes da décima terceira flag

Se eu recomeçasse, a primeira coisa depois do ETL não seria mais uma flag de scoring. Seria saber quando um dos quatro serviços parou de atualizar.

O modo de falha que assusta não é o serviço que cai. Esse você percebe na hora, porque o painel some. É o serviço que continua de pé servindo dado velho. O dashboard abre, os gráficos desenham, as 12 flags aparecem coloridas. E a decisão que você toma às oito da manhã está apoiada em preço velho.

Um sistema com três praças e mais de 8 milhões de registros por dia útil tem lugar demais para conferir no olho. A checagem que vale é a mais chata possível: qual foi o registro mais recente de cada praça e há quanto tempo ele entrou. Cabe numa consulta e num alerta, e rende mais que a décima terceira flag.

O que um sistema desses resolve nunca foi acertar para onde o mercado vai. Foi pegar um fluxo que não para — três praças, mais de 8 milhões de registros por dia útil, doze tarefas disparadas sem ninguém pedir — e devolver a mesma leitura, com o mesmo critério, toda manhã. Previsão é outro ofício. Consistência é engenharia, e essa parte dá para garantir.