PLANEJAMENTO DE CAPACIDADE
Planejamento de capacidade para um pipeline da API de odds da Pinnacle.
O planejamento de capacidade para a API de odds da Pinnacle transforma três decisões de produto em dois números: requisições por segundo e requisições por dia. Faça a aritmética antes de escolher um plano, e a API REST da Pinnacle vira um orçamento que você administra em vez de uma cota que você teme.
As três entradas
Toda estimativa de capacidade para odds da Pinnacle vem de três entradas, e cada uma é uma decisão de produto antes de ser técnica.
Esportes cobertos. O endpoint de mercados responde a um esporte por requisição e retorna todos os eventos dele, cada um com money line, spreads, totais e totais por equipe em todos os períodos. Cobrir quatro ligas de futebol ou todas as ligas de futebol custa a mesma requisição; cobrir cinco esportes custa cinco.
Fases. Quadros ao vivo e pré-jogo são requisições separadas com o mesmo formato. A documentação coloca a atualização pré-jogo em cerca de 30 segundos, então consultar mais rápido do que isso não traz nada. Preços ao vivo chegam ao feed em uma fração de segundo, então é no ao vivo que o intervalo importa.
Intervalo de polling. O intervalo decide quão atualizado é o seu estado e com que frequência você paga por ele. Reduzi-lo pela metade dobra as requisições sem mudar o escopo. Depois da primeira chamada o cursor since retorna apenas os eventos que mudaram, então um intervalo mais rápido adiciona requisições, mas pouca carga de dados.
A matemática: quadros ÷ intervalo
A fórmula tem uma linha. Requisições por segundo é igual aos quadros que você consulta, esportes vezes fases, dividido pelo intervalo em segundos. Quando ao vivo e pré-jogo rodam em intervalos diferentes, some as duas taxas. Requisições por dia é essa taxa vezes os segundos ativos em um dia.
Exemplos práticos, consultando todos os quadros o dia inteiro:
| Escopo | Intervalo de polling | Requisições / segundo | Requisições / dia |
|---|---|---|---|
| 5 esportes, ao vivo5 quadros por ciclo | 1 s | 5 | 432,000 |
| 5 esportes, ao vivo e pré-jogo10 quadros em dois intervalos | 5 s ao vivo, 30 s pré-jogo | 1.17 | 100,800 |
| Todos os 13 esportes, ao vivo e pré-jogo26 quadros em dois intervalos | 2 s ao vivo, 30 s pré-jogo | 6.93 | 599,040 |
Duas lições saem da aritmética. Primeira, o intervalo é a alavanca mais forte nos quadros ao vivo: passar de 5 segundos para 1 multiplica as requisições por cinco sem nenhuma cobertura a mais. Segunda, partidas não adicionam requisições; esportes e fases sim. Consulte 16 horas ativas em vez de 24 e todo número diário cai um terço, então conte horas ativas, não horas do calendário.
Folga para dias de jogo
Dias de jogo mudam a carga de dados, não a contagem de quadros. Quando uma rodada completa de sábado acontece, cada quadro carrega mais eventos e mais deles mudam entre consultas, então as respostas crescem e seu parser trabalha mais, enquanto um quadro continua sendo uma requisição.
As requisições crescem com os eventos quando você busca detalhes por evento, como todos os mercados de um evento pré-jogo ou suas linhas alternativas. Orce essas chamadas separadamente: 200 chamadas de detalhe a cada 30 segundos são cerca de 6,7 requisições por segundo sozinhas. O agrupamento de horários de início e a retentativa ocasional por timeout se somam por cima, exatamente quando você menos pode se dar ao luxo de dados defasados.
Dimensione para o pico, não para a média. Se a carga de pico exceder seu teto por segundo, o excesso não entra em fila, é rejeitado, e seu estado fica defasado durante os minutos que mais importam. Os padrões em tratamento de limites de taxa impedem que rejeições virem interrupções, mas folga é a solução de verdade.
Do volume a um plano da API da Pinnacle
Com as requisições por segundo no pico em mãos, combinar volume com um plano é mecânico. O acesso REST gratuito, 20 requisições por minuto e 100 requisições por dia, basta para inspecionar respostas e prototipar. O polling em produção precisa de capacidade paga: os níveis comparados neste site rodam a 10 e 30 requisições por segundo com volume diário ilimitado, então a taxa por segundo é o número a combinar.
Aplique a fórmula com suas próprias entradas e compare o valor de pico com os tetos na seção de planos. Um pico de 6 requisições por segundo cabe no nível de 10 por segundo. Todos os 13 esportes ao vivo a cada segundo são 13 por segundo, o que exige o nível de 30 por segundo.
Para transformar a mesma programação em um valor mensal, a calculadora de custo da API no pnclAPI recebe o intervalo, as horas ativas e os quadros e devolve requisições por período de cobrança.
Duas formas de reduzir a conta antes de fazer upgrade: as leituras incrementais em polling REST eficiente cortam chamadas desperdiçadas, e a disciplina de backoff em tratamento de 429 impede que retentativas queimem cota.