En un SaaS, un email de verificación que no llega suele provocar la misma reacción: reintentar. A veces funciona. Otras veces solo llena la cola, duplica mensajes y hace mas difícil saber qué ocurrió con la cuenta.
Un presupuesto de reintentos es una regla sencilla para que el backend sea resistente sin convertir cada fallo temporal en una tormenta. La idea no es enviar menos por ahorrar, sino decidir con claridad cuándo insistir, cuándo esperar y cuándo pedir ayuda al producto o al soporte.
Por qué reintentar no siempre arregla el onboarding
Un proveedor puede responder con un error temporal, una API puede tener latencia o un worker puede reiniciarse justo después de aceptar un mensaje. Esos casos justifican algún reintento. Pero un correo mal formado, un dominio bloqueado o un token ya usado no mejoran por repetir la misma operación.
La primera separación útil es entre fallos recuperables y fallos definitivos:
recuperable: timeout, 429, error temporal del proveedor
definitivo: dirección inválida, token expirado, plantilla ausente
Si todos terminan en la misma cola, el equipo pierde tiempo mirando síntomas. También puede retrasar emails válidos de otras cuentas. El objetivo del presupuesto es proteger la experiencia completa, no solo el mensaje individual.
Define un presupuesto pequeño
Para comenzar, prueba con un máximo de tres intentos durante quince minutos. El primer reintento puede ocurrir después de treinta segundos, el segundo después de dos minutos y el tercero después de diez. Son números de partida, no una ley: el proveedor, el tipo de flujo y la urgencia del producto deben decidir el ajuste.
Guarda estos datos en cada entrega:
{
"delivery_id": "del_123",
"user_id": "usr_456",
"attempt": 2,
"max_attempts": 3,
"next_attempt_at": "2026-11-05T05:30:00Z",
"reason": "provider_timeout",
"flow_version": "signup-v4"
}
Con attempt y max_attempts, el worker puede tomar una decisión visible. Con flow_version, puedes comprobar si un cambio en el onboarding modificó la tasa de fallos. No hace falta empezar con un sistema enorme; un registro bien definido ya da una señal util.
Diseña estados e idempotencia
Un envío debería tener estados que una persona pueda explicar: queued, sending, sent, retry_scheduled, delivered, failed o dead_letter. El nombre exacto importa menos que mantener una definición estable.
La idempotencia es igual de importante. Si el worker recibe dos veces el mismo trabajo, debe reconocer el delivery_id y evitar dos mensajes idénticos. Una clave única en la base de datos y una comprobación antes de llamar al proveedor suelen ser un buen comienzo.
No confundas sent con delivered. El primer estado significa que el proveedor aceptó la solicitud; el segundo necesita una confirmación posterior o una definición explícita del servicio. Esa diferencia evita prometer al usuario que ya recibió algo que solo salió de tu API.
Cuando el flujo tenga varios actores, ayuda pensar en estados antes que en reintentos. Este enfoque también aparece en una guía sobre estados y reintentos para agentes, y es aplicable a cualquier worker que procese eventos.
Observa la cola sin perder el contexto
Una métrica de reintentos aislada puede ser engañosa. Acompáñala con la tasa de activación, el tiempo hasta el primer envío y el número de cuentas que terminaron en dead_letter. Así podrás distinguir una cola ocupada de un problema real del producto.
También registra un motivo normalizado y un identificador de correlación. No guardes el contenido completo del mensaje en cada log; normalmente basta con la cuenta, el flujo y el código de error. Menos datos sensibles hacen mas facil revisar el incidente.
Si el problema crece, un runbook breve puede indicar quién revisa el proveedor, qué consultas ejecutar y cuándo pausar nuevos cambios. Los runbooks cortos para incidentes de email son una referencia práctica para convertir una alerta confusa en una secuencia manejable.
Para probar el sistema, usa cuentas controladas y fixtures separados. Una etiqueta como dummy e mail puede aparecer en un escenario de QA, pero no debe mezclarse con métricas reales ni con direcciones de clientes. El entorno de prueba necesita su propia limpieza y límites.
Errores comunes
El primer error es usar una espera fija para todos los fallos. Un timeout y una dirección inválida merecen caminos distintos. El segundo es reiniciar el contador cuando el proceso se despliega; el presupuesto pertenece al delivery_id, no a la vida del worker.
El tercero es esconder los mensajes agotados. Cuando una entrega alcanza el límite, muévela a una cola de revisión y muestra un estado que soporte pueda entender. Documenta qué significa cada salida; de lo contrario, cada equipo interpreta el tablero de una manera diferente.
Otro fallo común es aumentar el límite antes de conocer la causa. Un cuarto o quinto intento puede elevar el ruido sin mejorar la activación. Primero revisa los códigos, el proveedor y la versión del flujo. Despues cambia una variable y compara resultados.
Preguntas rápidas
¿Tres intentos siempre son suficientes?
No. Es un punto de partida para un flujo de registro. Un email de recuperación de cuenta puede requerir una política diferente, igual que una notificación interna. Lo importante es que la excepción esté documentada y tenga un dueño.
¿Debo reintentar después de un error 429?
Normalmente sí, respetando Retry-After cuando el proveedor lo envía. Si ignoras ese valor, puedes agravar el límite. Añade también un tope global para que muchos usuarios no creen una avalancha.
¿Qué hago con un mensaje agotado?
Marca el motivo final, conserva el contexto técnico mínimo y ofrece una acción clara: reenvío manual, cambio de dirección o revisión del proveedor. No lo dejes en un limbo que parezca enviado.
Recapitulación
Un presupuesto de reintentos convierte una intuición —“intentemos otra vez”— en una política que se puede probar. Separa fallos recuperables, limita los intentos, conserva el estado y mide el resultado en términos de activación, no solo de volumen de mensajes.
Empieza pequeño: tres intentos, estados claros, una clave idempotente y una cola de revisión. Cuando el equipo pueda explicar cada transición sin adivinar, el email dejará de ser una caja negra del onboarding y será una parte mas confiable del producto.
Top comments (0)