PLANIFICACIÓN DE CAPACIDAD
Planificación de capacidad para un pipeline de la API de cuotas de Pinnacle.
La planificación de capacidad para la API de cuotas de Pinnacle convierte tres decisiones de producto en dos números: solicitudes por segundo y solicitudes por día. Haz la aritmética antes de elegir un plan, y la API REST de Pinnacle se convierte en un presupuesto que gestionas en lugar de una cuota que temes.
Las tres entradas
Toda estimación de capacidad para cuotas de Pinnacle parte de tres entradas, y cada una es una decisión de producto antes que técnica.
Deportes cubiertos. El endpoint de mercados responde a un deporte por solicitud y devuelve todos sus eventos, cada uno con su money line, spreads, totales y totales por equipo en todos los periodos. Cubrir cuatro ligas de fútbol o todas las ligas de fútbol cuesta la misma solicitud; cubrir cinco deportes cuesta cinco.
Fases. Los tableros en vivo y prepartido son solicitudes separadas con la misma forma. La documentación sitúa la actualización prepartido en unos 30 segundos, así que sondear más rápido no aporta nada. Los precios en vivo llegan al feed en una fracción de segundo, así que en vivo es donde importa el intervalo.
Intervalo de sondeo. El intervalo decide cuán fresco es tu estado y con qué frecuencia pagas por él. Reducirlo a la mitad duplica las solicitudes sin cambiar el alcance. Tras la primera llamada el cursor since devuelve solo los eventos que cambiaron, así que un intervalo más rápido añade solicitudes pero poca carga de datos.
Las matemáticas: tableros ÷ intervalo
La fórmula es una línea. Solicitudes por segundo es igual a los tableros que sondeas, deportes por fases, dividido por el intervalo en segundos. Cuando en vivo y prepartido corren con intervalos distintos, suma las dos tasas. Solicitudes por día es esa tasa por los segundos activos de un día.
Ejemplos prácticos, sondeando todos los tableros todo el día:
| Alcance | Intervalo de sondeo | Solicitudes / segundo | Solicitudes / día |
|---|---|---|---|
| 5 deportes, en vivo5 tableros por ciclo | 1 s | 5 | 432,000 |
| 5 deportes, en vivo y prepartido10 tableros en dos intervalos | 5 s en vivo, 30 s prepartido | 1.17 | 100,800 |
| Los 13 deportes, en vivo y prepartido26 tableros en dos intervalos | 2 s en vivo, 30 s prepartido | 6.93 | 599,040 |
De la aritmética salen dos lecciones. Primera, el intervalo es la palanca más fuerte en los tableros en vivo: pasar de 5 segundos a 1 multiplica las solicitudes por cinco sin añadir cobertura. Segunda, los partidos no añaden solicitudes; los deportes y las fases sí. Sondea 16 horas activas en lugar de 24 y toda cifra diaria cae un tercio, así que cuenta horas activas, no horas de calendario.
Margen para los días de partido
Los días de partido cambian la carga de datos, no el número de tableros. Cuando se juega una jornada completa de sábado, cada tablero lleva más eventos y más de ellos cambian entre sondeos, así que las respuestas crecen y tu parser trabaja más, mientras que un tablero sigue siendo una solicitud.
Las solicitudes sí crecen con los eventos cuando obtienes detalle por evento, como todos los mercados de un evento prepartido o sus líneas alternativas. Presupuesta esas llamadas por separado: 200 llamadas de detalle cada 30 segundos son unas 6,7 solicitudes por segundo por sí solas. La concentración de horarios de inicio y el reintento ocasional por timeout se suman encima, justo cuando menos puedes permitirte datos obsoletos.
Dimensiona para el pico, no para la media. Si la carga máxima supera tu techo por segundo, el exceso no se encola, se rechaza, y tu estado queda obsoleto durante los minutos que más importan. Los patrones de manejo de límites de tasa evitan que los rechazos se conviertan en caídas, pero el margen es la solución real.
Del volumen a un plan de la API de Pinnacle
Una vez tienes las solicitudes por segundo en el pico, ajustar el volumen a un plan es mecánico. El acceso REST gratuito, 20 solicitudes por minuto y 100 solicitudes por día, basta para inspeccionar respuestas y prototipar. El sondeo en producción necesita capacidad de pago: los niveles comparados en este sitio funcionan a 10 y 30 solicitudes por segundo con volumen diario ilimitado, así que la tasa por segundo es el número que hay que ajustar.
Aplica la fórmula con tus propias entradas y compara la cifra máxima con los techos de la sección de planes. Un pico de 6 solicitudes por segundo cabe en el nivel de 10 por segundo. Los 13 deportes en vivo cada segundo son 13 por segundo, lo que necesita el nivel de 30 por segundo.
Para convertir la misma programación en una cifra mensual, la calculadora de costes de la API en pnclAPI toma el intervalo, las horas activas y los tableros y devuelve solicitudes por periodo de facturación.
Dos formas de reducir la factura antes de subir de nivel: las lecturas incrementales de sondeo REST eficiente recortan llamadas desperdiciadas, y la disciplina de backoff de manejo del 429 evita que los reintentos quemen cuota.