INTEGRAÇÃO REST
Faça polling da API REST da Pinnacle sem desperdício.
A maioria dos problemas de cota da API da Pinnacle são problemas de projeto. Uma integração disciplinada lê apenas o que mudou, lê uma vez só e espaça as chamadas. Quatro hábitos mantêm as odds da Pinnacle atualizadas no seu backend enquanto o volume de requisições fica estável.
O cursor since da API da Pinnacle
A API REST suporta leituras incrementais. Passe o cursor da resposta anterior e a próxima chamada retorna apenas o que mudou desde aquele ponto. Uma leitura completa de partidas em uma rodada movimentada pode retornar centenas de eventos; uma leitura incremental depois de um minuto calmo retorna um punhado, muitas vezes nenhum.
Armazene o cursor no servidor, ao lado dos snapshots que ele produziu, em Redis, Postgres ou no que guardar seu estado de mercado. Cada execução do poller lê o cursor, passa-o com a requisição e depois persiste o novo cursor junto com o estado mesclado. Depois de um deploy ou reinício, retome do cursor armazenado em vez de começar do zero.
O antipadrão a evitar: reler snapshots completos em um timer. Parece seguro, mas move muito mais dados do que leituras por cursor (o próprio exemplo da documentação é 1.522 eventos para um quadro pré-jogo completo de futebol contra 7 eventos alterados na leitura incremental seguinte) e faz seu parser refazer trabalho que não mudou. Snapshots completos são para a primeira inicialização e recuperação de desastres, não para o regime normal.
Cache e reutilização a jusante
Um leitor, muitos consumidores. Seu dashboard, modelo de precificação, serviço de liquidação e jobs de alerta leem todos o seu próprio armazenamento, nunca a API. Cinquenta consumidores internos custam exatamente o mesmo volume upstream que um, porque só o poller chama o upstream.
O cache também é a fronteira de segurança. A chave da API vive no poller, no servidor. Navegadores e aplicativos cliente chamam seu backend, que responde a partir da própria cópia com seus próprios metadados de atualidade. A arquitetura do pipeline na página inicial descreve o formato: busque uma vez, normalize, sirva suas próprias interfaces.
A reutilização muda a pergunta de capacidade de quantos usuários você tem para quão rápido os preços se movem, que é a pergunta que o planejamento de capacidade de fato responde.
Ritme as requisições de forma uniforme
Um limite por segundo cobra por rajadas, não por médias. Dez chamadas de quadro devidas a cada 5 segundos devem sair uma a cada 500 milissegundos, não dez no início da janela. O ritmo uniforme mantém a taxa instantânea abaixo do teto e deixa espaço para retentativas e chamadas de detalhe por evento.
Evite o alinhamento com o início do minuto. Uma entrada de cron que dispara no minuto cheio começa no mesmo segundo que todos os outros clientes acionados por cron na internet, e as APIs sentem isso. Desloque sua agenda e, em cada ciclo, distribua as chamadas com uma fila simples: intervalo dividido por chamadas vira o atraso entre requisições.
O exemplo prático da página inicial calcula exatamente essa taxa distribuída uniformemente. Se seu agendador não consegue manter esse formato, o limite efetivo que você experimenta é menor do que o número do plano, e o primeiro sintoma é o padrão de 429 coberto em tratamento de limites de taxa.
Tratando falhas
Leituras vão falhar: timeouts, um 5xx do upstream, um 429 quando uma rajada escapa. Projete para falhas no poller, não nos consumidores.
Defina o timeout do cliente bem abaixo do intervalo de polling para que uma leitura travada não paralise o próximo ciclo. Tente de novo com backoff exponencial e jitter, respeite o Retry-After em respostas 429 e limite as tentativas para que um minuto ruim não se multiplique em um pico de tráfego. O guia de limites de taxa percorre o padrão com pseudocódigo.
Entre falhas, continue servindo o último snapshot bom e marque-o como defasado. Uma exibição de odds com 20 segundos de idade e rotulada é melhor do que uma vazia. Se as perdas se acumularem, a solução costuma ser volume, não heroísmo: revise o cursor, a taxa de acerto do cache e o ritmo antes de mexer no plano.