INTEGRACIÓN REST
Sondea la API REST de Pinnacle sin desperdicio.
La mayoría de los problemas de cuota de la API de Pinnacle son problemas de diseño. Una integración disciplinada lee solo lo que cambió, lo lee una vez y espacia las llamadas. Cuatro hábitos mantienen frescas las cuotas de Pinnacle en tu backend mientras el volumen de solicitudes se mantiene plano.
El cursor since de la API de Pinnacle
La API REST admite lecturas incrementales. Pasa el cursor de la respuesta anterior y la siguiente llamada devuelve solo lo que cambió desde ese punto. Una lectura completa de partidos en una jornada cargada puede devolver cientos de eventos; una lectura incremental tras un minuto tranquilo devuelve un puñado, a menudo ninguno.
Guarda el cursor en el servidor, junto a los snapshots que produjo, en Redis, Postgres o donde vivan tus datos de mercado. Cada ejecución del sondeador lee el cursor, lo pasa con la solicitud y luego persiste el nuevo cursor junto con el estado fusionado. Tras un despliegue o un reinicio, reanuda desde el cursor guardado en lugar de empezar de cero.
El antipatrón a evitar: releer snapshots completos con un temporizador. Parece seguro, pero mueve muchos más datos que las lecturas por cursor (el propio ejemplo de la documentación es 1.522 eventos para un tablero prepartido completo de fútbol frente a 7 eventos cambiados en la lectura incremental posterior) y hace que tu parser rehaga trabajo que no cambió. Los snapshots completos son para el primer arranque y la recuperación ante desastres, no para el régimen normal.
Cachea y reutiliza aguas abajo
Un lector, muchos consumidores. Tu panel, tu modelo de precios, tu servicio de liquidación y tus trabajos de alertas leen todos tu propio almacén, nunca la API. Cincuenta consumidores internos cuestan exactamente el mismo volumen upstream que uno, porque solo el sondeador llama upstream.
La caché es también la frontera de seguridad. La clave de la API vive en el sondeador, en el servidor. Los navegadores y las apps cliente llaman a tu backend, que responde desde su propia copia con sus propios metadatos de frescura. La arquitectura del pipeline de la página de inicio describe la forma: obtén una vez, normaliza, sirve tus propias interfaces.
La reutilización cambia la pregunta de capacidad de cuántos usuarios tienes a cuán rápido se mueven los precios, que es la pregunta que la planificación de capacidad realmente responde.
Marca un ritmo uniforme a las solicitudes
Un límite por segundo te cobra por ráfagas, no por medias. Diez llamadas de tablero que vencen cada 5 segundos deberían salir una cada 500 milisegundos, no diez al inicio de la ventana. El ritmo uniforme mantiene la tasa instantánea por debajo del techo y deja espacio para reintentos y llamadas de detalle por evento.
Evita la alineación con el inicio del minuto. Una entrada de cron que se dispara al minuto exacto empieza en el mismo segundo que todos los demás clientes basados en cron de internet, y las APIs lo notan. Desplaza tu calendario y, dentro de cada ciclo, reparte las llamadas con una cola simple: el intervalo dividido por las llamadas es el retardo entre solicitudes.
El ejemplo práctico de la página de inicio calcula exactamente esta tasa distribuida uniformemente. Si tu programador no puede mantener esa forma, el límite efectivo que experimentas es menor que la cifra del plan, y el primer síntoma es el patrón de 429 que cubre manejo de límites de tasa.
Gestionar fallos
Las lecturas fallarán: timeouts, un 5xx del upstream, un 429 cuando se cuela una ráfaga. Diseña para el fallo en el sondeador, no en los consumidores.
Fija el timeout del cliente muy por debajo del intervalo de sondeo para que una lectura colgada no pueda bloquear el siguiente ciclo. Reintenta con backoff exponencial y jitter, respeta Retry-After en las respuestas 429 y limita los intentos para que un mal minuto no se multiplique en un pico de tráfico. La guía de límites de tasa recorre el patrón con pseudocódigo.
Entre fallos, sigue sirviendo el último snapshot bueno y márcalo como obsoleto. Una pantalla de cuotas de hace 20 segundos y etiquetada es mejor que una vacía. Si los fallos se acumulan, la solución suele ser volumen, no heroicidades: revisa el cursor, la tasa de aciertos de la caché y el ritmo antes de tocar el plan.