Comparte una clave de la API de Pinnacle entre sondeadores sin 429

Una clave de la API de Pinnacle, cinco deportes, tres procesos: al límite de tasa no le importa cuántos workers ejecutas. El techo por segundo pertenece a la clave, así que cada worker que añades gasta del mismo presupuesto. El diseño que funciona divide los tableros entre workers, les marca el ritmo contra un limitador compartido y mantiene un cursor por tablero.

El techo pertenece a la clave

Todo plan lleva una cuota por segundo, y cruzarla devuelve 429 con una cabecera Retry-After, como documenta la guía de límites de tasa, verificado el 2026-10-01. Dos sondeadores corriendo a 6 solicitudes por segundo cada uno en un nivel de 10 por segundo son una carga de 12 por segundo para la API. El primer número a computar, por tanto, no es la velocidad de ningún worker sino el total: deportes por fases dividido entre el intervalo, sumado sobre todo lo que corre.

Divide los tableros, no las solicitudes

Da a cada worker su propia porción de la cobertura: un conjunto de deportes y fases que ningún otro worker toca. Dividir vence a compartir una cola de tareas por una razón: el cursor since es por tablero. Un worker dueño de sus tableros es dueño de sus cursores, los guarda junto a los snapshots que produjeron y los retoma tras un reinicio sin coordinarse con nadie.

Dos workers sondeando el mismo tablero no dividen el coste del tablero a la mitad. Lo duplican.

Marca el ritmo contra un presupuesto compartido

El estado de backoff tiene que ser compartido, porque diez procesos retrocediendo cortésmente aún suman diez veces las solicitudes, como advierte la guía de límites de tasa. Lo mismo vale para el ritmo. Un pequeño limitador compartido, por ejemplo un token bucket en Redis que cada worker consulta antes de una llamada, mantiene la tasa agregada bajo el techo por mucho que las agendas individuales deriven.

Mantén el uso estacionario por debajo de cerca del 70 por ciento del techo. En un nivel de 10 por segundo, eso es 7 por segundo entre todos los workers combinados, dejando el resto para reintentos, resincronizaciones y la lectura completa ocasional del tablero, según la regla de margen de la misma guía.

Observa el agregado, no los workers

Los logs por worker mienten por omisión: cada worker puede parecer sano mientras la suma está sobre el presupuesto. Sigue la tasa total de solicitudes y el recuento de 429 de la clave, y alerta sobre eso, no sobre un proceso aislado. La guía de planificación de capacidad convierte deportes, fases e intervalo en la cifra por segundo que comparas con el techo. Ejecuta esa aritmética antes de añadir un worker, no después de la primera tormenta de 429.

Una clave, un presupuesto, muchos workers. Divide los tableros, comparte el limitador, y el techo deja de ser una sorpresa.