SRE: un presupuesto de latencia para emails

Una verificación de correo puede fallar aunque todos los servicios estén “arriba”. El usuario recibe el mensaje, pero llega después del timeout; el test reintenta, consume el segundo mensaje y termina pasando por casualidad. En los dashboards, la primera pista suelen ser varias alertas pequeñas que nunca forman una historia completa.

Para SRE, este problema se entiende mejor como un presupuesto de latencia. No basta con decir que el email debe llegar “rápido”. Hay que repartir el tiempo entre la aplicación, la cola, el adaptador, el proveedor y el lector que confirma el mensaje. Así una prueba en Kubernetes puede explicar dónde se gastó cada segundo y cuándo conviene abrir un incidente.

El síntoma: el correo llega, pero el servicio parece caído

Imagina un flujo con un límite total de 90 segundos:

• 10 segundos para crear la cuenta y solicitar el mensaje.
• 20 segundos para que la aplicación lo ponga en la cola.
• 40 segundos para entrega y lectura del buzón.
• 20 segundos de margen para reintentos controlados.

Si el mensaje llega al segundo 86, el sistema está cerca del límite aunque el endpoint de signup responda en 200 ms. Si llega al segundo 110, el usuario ve un fallo, pero el correo atrasado puede activar un enlace que ya no corresponde a su intento.

La diferencia importa. Un error de aplicación pide una corrección de código; una demora de cola pide observabilidad, capacidad o una política distinta de espera. Mezclar ambas cosas produce alertas ruidosas y runbooks poco utiles.

También conviene distinguir entre correo entregado y correo observado. El proveedor puede aceptar un mensaje mientras el adaptador todavía no ha actualizado su índice. En una prueba con temp mail email, la dirección temporal es solo el destino: no reemplaza un identificador de ejecución ni una métrica de entrega.

Define un presupuesto de latencia por etapa

Empieza con un contrato sencillo. Cada etapa debe registrar started_at, finished_at y un run_id estable. El contrato podría verse así:

signup.request       0s  - 10s
mail.enqueue         0s  - 20s
mail.delivery        0s  - 40s
mail.observation     0s  - 70s
verification.submit  0s  - 90s

Los rangos no son una promesa universal. Son una hipótesis que se valida con ejecuciones reales. Si el adaptador consume normalmente en 12 segundos, asignarle 40 segundos puede ocultar una regresión. Si una región tiene una cola más lenta, reducir el timeout del test solo crea falsos negativos.

Usa el mismo run_id en la solicitud, en los metadatos del mensaje y en los logs del consumidor. No incluyas la dirección completa en nombres de pods o etiquetas; termina apareciendo en eventos, métricas y artefactos. Una identificación corta y opaca es mas fácil de buscar y reduce exposición innecesaria.

Para comprobar la relación entre red y entrega, ayuda tener un runbook de correos durante cambios de red. El objetivo no es atribuir cada demora a la red, sino comprobar si el cambio afectó una etapa concreta del presupuesto.

Instrumenta la ejecución en Kubernetes

Cada ejecución de CI debería tener un namespace o al menos un conjunto de etiquetas propio. El job del test puede guardar el estado antes de limpiar los recursos:

set -euo pipefail

namespace="email-check-${CI_RUN_ID}"
kubectl create namespace "$namespace"
kubectl label namespace "$namespace" owner=ci run-id="$CI_RUN_ID"

cleanup() {
  kubectl -n "$namespace" get pods,events -o wide > artifacts/k8s-state.txt || true
  kubectl delete namespace "$namespace" --ignore-not-found=true
}
trap cleanup EXIT

kubectl -n "$namespace" apply -f email-fixture/
kubectl -n "$namespace" wait --for=condition=Ready pod -l app=mail-adapter --timeout=120s
./run-email-test --run-id "$CI_RUN_ID"

El artefacto debe incluir el tiempo de cada etapa, el estado del pod y el motivo del último reintento. No guardes tokens de verificación sin redacción. Si se necesita el mensaje completo para investigar, usa un artefacto de corta duración y limita quién puede leerlo.

El aislamiento evita otro fallo común: una ejecución lenta lee el mensaje creado por una ejecución anterior. Para mantener el sistema limpio, asigna un TTL al namespace y borra el buzón de prueba junto con los recursos. La limpieza tiene que ser idempotente, porque una cancelación puede dejar el namespace a medias.

Separa una alerta útil de una alerta fantasma

Una alerta de producción no debería dispararse por un solo test lento. Primero define qué mide cada señal:

1. Error de solicitud: la aplicación no pudo crear el intento.
2. Retraso de cola: el mensaje no salió a tiempo del productor.
3. Retraso de entrega: salió, pero no fue aceptado en el plazo esperado.
4. Retraso de observación: el mensaje existe, pero el adaptador no lo encontró.
5. Verificación vencida: el enlace o el intento ya no era válido.

La alerta puede combinar percentiles de latencia con una tasa mínima de ejecuciones. Una sola prueba con tepm mail com o temp gamil com escrito por accidente no debería cambiar el estado global del servicio. En cambio, varias ejecuciones con el mismo tramo lento sí merecen una investigación.

Para los tests de onboarding, es útil mantener las métricas limpias al probar correos. Las ejecuciones sintéticas deben etiquetarse de forma que puedan excluirse de ciertos indicadores de negocio, pero no de los indicadores técnicos de entrega.

Checklist para el próximo incidente

Antes de cerrar un cambio en el flujo de email, revisa:

• ¿Cada ejecución tiene un run_id que viaja por todas las etapas?
• ¿El presupuesto separa cola, entrega y observación?
• ¿El test evita aceptar un mensaje de otra ejecución?
• ¿Los logs redaccionan tokens y direcciones completas?
• ¿El namespace y el buzón tienen una expiración definida?
• ¿El artefacto conserva evidencia antes de la limpieza?
• ¿Las alertas necesitan una cantidad mínima de muestras?

El resultado buscado no es que todos los correos lleguen instantáneamente. Es que un retraso sea explicable. Con un presupuesto pequeño, etiquetas consistentes y limpieza automática, Kubernetes deja de ser una caja negra para las pruebas de email. Y SRE puede decidir si el problema pide capacidad, un timeout mejor o una corrección en la aplicación, en vez de perseguir otra alerta fantasma.