Identificar el límite alcanzado
HTTP 429 indica exceso de solicitudes y puede incluir Retry-After. El cómputo y su alcance dependen del servicio. Una media baja no impide superar un límite de ventana corta.
| Concepto | Qué limita | Acción útil |
|---|---|---|
| Cuota | Volumen durante un período | Planificar el presupuesto compartido. |
| Ritmo | Llegadas en una ventana corta | Espaciar los inicios. |
| Concurrencia | Operaciones en curso | Limitar el trabajo simultáneo. |
| Retry-After: 120 | Espera de 120 segundos | Comprobar plazo y seguridad del reintento. |
Organizar la demanda autorizada
- Compruebe la clave de cómputo: cuenta, proyecto, usuario o ruta. Revise zona horaria de reinicio, coste por operación y presupuesto compartido.
- Suavice ráfagas con una cola acotada y limite por separado operaciones en curso. Propague cancelaciones y descarte tareas ya inútiles.
- Interprete Retry-After como fecha HTTP o espera en segundos. Respételo dentro del plazo total; establezca espera limitada si falta.
Evaluar sin eludir la protección
Un 429 no demuestra que sea seguro repetir la operación. Compruebe idempotencia, tiempo total e intentos. Mida rechazos y cola; si la demanda sostenida excede el contrato, reduzca necesidades o acuerde capacidad adecuada.
Fuentes primarias
Haga observable el abuso de los límites de uso.
Los límites de solicitud funcionan mejor cuando distinguen el uso legítimo del comportamiento anómalo y generan un evento interpretable. Los códigos de error por sí solos pueden ocultar el inicio, la duración y el alcance de un patrón de abuso.
- Registre el umbral, la decisión, la ruta y el contexto mínimo sin secretos.
- Correlacione las denegaciones repetidas con los efectos en los usuarios legítimos.
- Compruebe que las alertas conduzcan a una investigación o a un ajuste proporcional.
Fuente primaria: ACSC and partners — Event logging and threat detection. Método relacionado: consultar la guía práctica.