Reduciendo latencia de entrega OTP de 14 segundos a 3 segundos para una fintech colombiana

La reconstrucción de infraestructura fue directa en forma: pool transaccional dedicado en una /28 en nuestro datacentre de Países Bajos, aislado de cualquier tráfico de email marketing; throttling por ISP afinado para el panorama de receptores colombianos; monitoreo agresivo en latencia por mensaje en vez de solo reputación por día. El trabajo de entregabilidad fue territorio de Femke.

La migración DMARC a p=reject fue trabajo de Lieke. El plan de migración empezó con una baseline parsedmarc de qué receptores estaban actualmente reportando contra la política existente p=none — una ventana pasiva de observación de 14 días. Una vez supimos con qué receptores necesitábamos alinearnos (Gmail, Hotmail, Yahoo, los carriers colombianos mayores) y qué sources de envío legítimos existían (la fintech misma, su Zendesk transaccional, su tooling HR interno, dos integraciones SaaS), construimos el runbook de migración. La migración a p=quarantine ocurrió en el mes 3, a p=reject en el mes 6.

El lado compliance Habeas Data fue el engagement de Sanne. El DPA existente fue reconstruido desde cero en un documento de 14 páginas en español que abordaba Habeas Data específicamente, incluía el workflow de pedidos de acceso de sujetos de datos alineado con la Superintendencia, mapeaba el schedule de transferencias transfronterizas explícitamente (operamos desde jurisdicciones UE y PA; Habeas Data tiene provisiones específicas sobre transferencia transfronteriza que necesitaban tratamiento dedicado), y tenía la sección de derechos de auditoría que el equipo de compliance del cliente específicamente quería. El nuevo DPA fue filed con la Superintendencia en el mes 4.

El trabajo de latencia OTP merecía su propio stream de ingeniería. La latencia p95 de 14 segundos no era primariamente un problema de entregabilidad — era un problema de stack end-to-end. Instrumentamos el camino completo: app server → vendor API → vendor SMTP → MX receptor → buzón. Encontramos que ~9 segundos de la p95 de 14 segundos estaban dentro de la capa de queueing API del vendor (estaban batcheando envíos transaccionales en ventanas de 2 segundos por razones de cost-efficiency que no tenían sentido para OTP). La infraestructura dedicada removió ese batching por completo. De los 5 segundos restantes: ~2 segundos eran resolución DNS y handshake TLS (mejorado calentando el connection pool del lado del receptor), ~1,5 segundos era entrega SMTP real, y ~1,5 segundos era latencia de spam-filtering del lado receptor (que no podemos controlar completamente pero que cayó después del trabajo de reputación porque el correo filtrado pasa por caminos más rápidos).

La configuración PowerMTA para transaccional fintech difiere de PMTA de email-marketing en unas pocas formas clave. Primero, la estrategia de cola: en vez del patrón estándar "queue hasta que la ventana throttle abra", transaccional usa la configuración smtp-source-host para bypassear queueing para mensajes OTP por completo — el comando SMTP DATA sale dentro de milisegundos del API call. Segundo, la política de retry: el email marketing reintenta gracefully a lo largo de 24-72 horas; el OTP transaccional tiene un budget de retry de 90 segundos total antes de que el mensaje sea logged como failed y el UI customer-facing surface un prompt "reenviar OTP". Tercero, el techo de rate-limit por IP es mucho más alto porque el volumen transaccional es bursty en una forma que el volumen marketing no es.

El tuning específico UNE fue la pieza más complicada de ingeniería de receptor. El comportamiento de greylisting de UNE es más agresivo que el de Gmail o Hotmail — parecen deferir conexiones SMTP first-time de senders desconocidos por 60-90 segundos, lo cual está bien para email marketing pero es inaceptable para OTP. El workaround fue pre-calentar el connection pool UNE-bound enviando tráfico transaccional non-OTP periódico durante la ventana de warmup, construyendo una relación recognised-sender antes de que el tráfico OTP de producción rampeara. Esto funcionó porque el cache de greylisting UNE es por par-IP y persiste por ~30 días.

El trabajo de warmup TLS y DNS importa para latencia transaccional en una forma que no importa para marketing. Pre-resolvemos los registros MX de receptor para los receptores colombianos mayores y mantenemos el cache DNS caliente con un refresh de TTL de 5 minutos. Pre-establecemos sesiones TLS a los receptores mayores y las mantenemos vivas con heartbeats periódicos. Ambas agregan costo de infraestructura mínimo y rasuran ~1,5 segundos de la entrega OTP cold-start.

La estrategia DKIM es por tipo-de-mensaje, no por dominio. Los mensajes OTP son firmados con un selector dedicado que podemos depreciar rápidamente si es necesario (una infraestructura OTP comprometida es el escenario worst-case de breach fintech). Los mensajes de verificación KYC, confirmación de transacción y alerta de seguridad cada uno tiene su propio selector. El email marketing — el poco que existe — está firmado con un selector enteramente distinto. Esta separación nos deja aislar cualquier incidente de signing-key a un solo tipo de mensaje.

El trabajo de compliance Habeas Data tocó tanto ingeniería como contrato. En ingeniería: documentamos cada transferencia transfronteriza de datos en la infraestructura email, desde el hand-off de mensaje en el edge API hasta la entrega final al MX del receptor. Los puntos transfronterizos (datos saliendo de CO en el edge API, datos cruzando el Atlántico entre PA y UE, datos siendo entregados a receptores domiciliados fuera de CO) cada uno fue documentado en el DPA con la cláusula de justificación Habeas Data relevante. En contrato: la cláusula de derechos de auditoría fue negociada para darle al equipo de compliance del cliente el derecho de inspeccionar nuestros logs PMTA para mensajes relacionados con su dominio con 24 horas de aviso — un derecho que han ejercido en realidad dos veces en el período del engagement, ambas durante auditorías regulatorias.

La cadencia de reporting es diaria para latencia OTP (p50, p95, p99 publicado en un dashboard al que el equipo de ingeniería del cliente tiene acceso) y mensual para el summary ejecutivo. El summary ejecutivo está en español; los labels del dashboard de ingeniería están en inglés por preferencia del cliente (su equipo de ingeniería es bilingüe pero trabaja en inglés internamente).