Un servicio de correo temporal tiene varios tipos de carga de trabajo: generar direcciones, listar correos, abrir cuerpos, recibir tráfico SMTP y ejecutar trabajos administrativos. Un límite global único no puede expresar todos sus riesgos.
Coloque verificaciones baratas primero
Valide la ruta, el método, el tamaño de entrada y las credenciales requeridas antes de realizar trabajos costosos en la base de datos o en el almacenamiento de objetos. Use cachés limitadas para metadatos adecuados y evite crear estado ilimitado por clave a partir de identificadores no verificados. Las verificaciones de acceso aún deben aplicarse a las respuestas en caché.
Presupueste cada carga de trabajo
| Carga de trabajo | Control útil |
|---|---|
| Encuesta de buzón anónimo | Presupuestos de solicitud, guía de retroceso y validación de sesión. |
| Uso autenticado de la API | Límites asociados con la credencial y la operación. |
| Ingesta SMTP | Límites de conexión, tamaño de mensaje y trabajo por destinatario. |
| Trabajos de mantenimiento | Pequeños lotes y concurrencia limitada. |
Distinguir un pico de abuso continuo
Un cliente legítimo puede reintentar después de una falla de red. Registre suficiente información para distinguir ese pico del tráfico sostenido que ignora los límites. Las respuestas graduadas pueden incluir ralentizar las solicitudes, rechazo temporal o revocación de credenciales cuando la evidencia y la política lo justifiquen.
Verificar la ruta de falla
Pruebe que una solicitud rechazada no realice aún el trabajo costoso. Confirme que los clientes bien comportados entienden las respuestas de reintento y que el acceso privilegiado al buzón no pueda eludirse cambiando el punto final.
Esta es una lista de verificación arquitectónica, no una afirmación de que cada control esté habilitado en cada despliegue. Los límites de servicio actuales y las reglas de acceso deben tomarse de la documentación del sitio y de las respuestas de la API.