Vídeo · Criterio de ingeniería
Cuando falta criterio, una mejora acaba siendo un retroceso
Un ticket de rate limiting, una implementación técnicamente correcta y un cliente corporativo detrás de un NAT. El problema nunca estuvo en el código.
«Entiende el sistema, ten criterio, piensa de forma crítica». De tanto repetirlo ha dejado de significar nada, así que en este vídeo lo bajo a un caso concreto: un ticket pide limitar el endpoint de pagos a 10 peticiones por minuto por usuario; un agente de IA lo implementa impecablemente en el WAF, con su ventana de 60 segundos y su Terraform; tres días después un cliente corporativo con cientos de empleados, todos detrás del mismo NAT, comparte un único cubo y empieza a comerse el límite, mientras que quien abusa de verdad lo esquiva rotando de IP. La implementación era coherente, la infraestructura tenía sentido y los tests pasaban. Lo que no decidió nadie fue qué significa «usuario», que era justamente el ticket entero. Ocho minutos, en inglés, sobre dónde queda el criterio de ingeniería cuando escribir el código deja de ser el cuello de botella.
Puntos clave
- El WAF y el API Gateway protegen el borde y absorben los picos de tráfico. Ninguno de los dos debería ser quien decide qué usuario autenticado hay detrás de una petición.
- «Por usuario» y «por IP» parecen lo mismo hasta que aparece un NAT corporativo: entonces limitas juntos a quienes no deberías, y quien rota de IP se cuela sin despeinarse.
- La clave de idempotencia abre la pregunta que el ticket no traía: si el primer intento falló a medias, ¿ese reintento consume cuota? No hay respuesta universal, pero alguien tiene que firmar la que elijas.