Operaciones agrupadas y alias

Un limitador de frecuencia es un contador con una clave. La pregunta que decide si sirve o no es qué incrementa esa cuenta. En una API de rutas la respuesta es casi siempre la misma, porque una petición HTTP equivale a una operación. En GraphQL eso deja de ser cierto por dos caminos distintos.

El primero es el agrupamiento: el cuerpo de una sola petición puede llevar varias operaciones, que el servidor resuelve una tras otra. El segundo son los alias, que permiten pedir el mismo campo varias veces dentro de una misma operación dándole a cada copia un nombre distinto en la respuesta; son una comodidad del lenguaje —comparar dos fichas en una pantalla, por ejemplo— y multiplican el trabajo sin multiplicar las peticiones. Un contador que mira la petición desde fuera no ve ninguno de los dos.

Abre el laboratorio y lee registro-pasarela.txt. La cuarta columna dice cuántas operaciones traía el cuerpo de cada petición, un dato que la pasarela escribe después de que el limitador ya decidió. Busca la línea con el número más alto de esa columna.

La política de límites fija cuántas operaciones puede llevar como máximo una petición, aunque ese tope se quedó sin implementar. Léelo en politica-limites.txt y cuenta en el registro cuántas peticiones lo superan. Cuenta peticiones, no cuentas.

Hay una línea distinta de las demás: trae una sola operación y, dentro de ella, decenas de alias del mismo campo. La última columna del registro dice cuál. Crúzala con los tiquetes de soporte y verás por qué el panel de la campaña marca muchos más canjes que personas.

El informe tiene que decir dónde se cuenta, no solo que se cuente más bajo. Mientras la unidad del contador sea la petición HTTP, bajar el límite de ciento veinte a treinta no cambia nada para quien agrupa. La unidad tiene que ser la operación, y para las operaciones que valen dinero —canje, pago, recuperación— el contador tiene que vivir donde se resuelve la operación, que es el único sitio que sabe cuántas veces se intentó de verdad.