Campañas de correo para millones de destinatarios, al ritmo que tu dominio aguanta

Qué es

Un despachador de campañas masivas, en producción, que envía campañas de correo a millones de destinatarios al ritmo que tu dominio de envío aguanta. Corre en tu propia cuenta de nube: tu equipo sube una lista de contactos y una plantilla HTML, cuyas variables se llenan con cualquier columna de la lista, elige cuándo enviar, y la plataforma hace el resto. Cada correo lleva la marca de su campaña, así que entregas, aperturas, clics, rebotes y quejas vuelven como cifras por campaña y como un reporte por destinatario.

El problema que resuelve

Con millones de destinatarios, enviar una campaña es un problema de ingeniería, no un botón. Si sale toda de golpe, los proveedores de correo ven una avalancha repentina desde tu dominio: buena parte termina en spam, y la reputación del dominio sufre en cada campaña siguiente. Si sale desde una suite de mercadeo que cobra por contacto, las listas grandes se encarecen rápido y terminan recortándose para ahorrar.

Luego llegan las preguntas: ¿le llegó a este cliente? ¿Por qué rindió poco esa campaña? Los datos de quién recibió qué viven en el sistema de otro, y cada nueva unidad de negocio significa otro contrato.

Qué obtienes

• Campañas a millones de destinatarios, enviadas con confiabilidad: una lista de cualquier tamaño fluye por el remitente, y una campaña que falla nunca se reenvía sola.
• Envíos que cuidan tu dominio: un ritmo constante y controlado que subes a medida que tu reputación se calienta, sin desplegar.
• Una respuesta a “¿le llegó a este cliente?”: un reporte por destinatario con cada evento, junto a las columnas de tu propia lista.
• Campañas que salen a tiempo sin que nadie las vigile: programas un envío y arranca cuando corresponde.
• Un costo que sigue a lo que envías: pagas al servicio de correo de la nube por mensaje, no a una suite por contacto, y casi nada entre campañas.
• Un mismo diseño para cada unidad de negocio: cada una tiene su cuenta y su identidad de remitente, desplegadas desde el mismo código.

Cómo lo entregamos

Como un proyecto de Integración de Sistemas. Desplegamos la plataforma en tu cuenta de nube, verificamos tus dominios de envío, conectamos los eventos de correo al archivo de reportes y acordamos un plan de calentamiento que sube el ritmo de envío paso a paso. Tu herramienta de campañas o tu front end interno se comunica con ella por una API pequeña. Necesitamos acceso a la cuenta, control de tus registros DNS y una muestra del formato de tu lista. Después del lanzamiento, un Retainer de Ingeniería cubre nuevas unidades de negocio, cambios de ritmo y nuevos reportes.

¿Es para ti?

Encaja si envías campañas grandes desde listas que ya tienes, quieres los datos y la factura en tu propia cuenta de nube, y necesitas demostrar qué pasó con cualquier correo. No es para ti si tu equipo necesita un editor de arrastrar y soltar, recorridos de cliente o pruebas A/B: esto envía campañas preparadas desde un archivo. Tampoco es para correo transaccional que se dispara uno a uno, y con volúmenes pequeños una herramienta de mercadeo alojada es más simple.

Objetivos de diseño

1. Los envíos nunca van más rápido de lo que aguanta la reputación del dominio.
2. Las listas y plantillas nunca pasan por la API; van directo al almacenamiento.
3. Un envío que se cae nunca se reanuda ni se repite solo; lo decide una persona.
4. Cada correo lleva la marca de su campaña, así que cada evento se rastrea hasta ella.
5. El trabajo pesado solo corre mientras hay una campaña que preparar o un reporte que construir.

Arquitectura

1. Personas y disparadores

   Equipo de mercadeoSube lista y plantilla

   ProgramadorCampañas pendientes, refresco de métricas

2. Aplicaciones

   API de campañasServerless, enlaces de carga temporales

   Trabajos de preparaciónContenedores bajo demanda

   Worker de envíoLee la cola, envío controlado

3. Estado

   Registros de campañaEstado, programación, métricas

   ArchivosListas, plantillas, reportes

   ColaCampañas listas para enviar

4. Envío y seguimiento

   Servicio de correoEnvía, emite cada evento

   Archivo de eventosParticionado por día

   Motor de consultasSQL sobre eventos y listas

Cada pieza tiene el tamaño de su uso. La API de campañas es una sola función serverless detrás de un gateway HTTP: se llama unas pocas veces por campaña y pasa el resto del día sin hacer nada. Crear una campaña devuelve dos enlaces de carga con vencimiento, uno para la lista y otro para la plantilla, así que el navegador sube los archivos directo al almacenamiento y la API nunca los toca.

Los registros de campaña viven en una tabla clave-valor con cobro por solicitud, con índices por estado y por fecha de creación. El campo de estado (creada, programada, encolada, enviando, completada, abortada, fallida) es lo que leen el programador, el worker y los reportes, así que hay un solo lugar para ver en qué va cualquier campaña.

Los trabajos de preparación y de reportes corren en contenedores bajo demanda. Dejar lista una lista grande, o construir un reporte por destinatario, puede tardar más de lo que se le permite a una función, y nada debería cobrar entre campañas.

El worker de envío es un contenedor pequeño alimentado por una cola. Escala según la profundidad de la cola con un tope de uno, así que dos campañas nunca compiten por el mismo ritmo de envío.

El seguimiento corre sobre archivos, no sobre una base de datos de eventos. El servicio de correo publica cada evento de la configuración de la campaña en un archivo particionado por día, y un motor de consultas corre SQL sobre él.

Cómo resolvemos lo difícil

Enviar al ritmo que aguanta la reputación

1. Leer la listaPor lotes, la memoria no crece
2. PersonalizarMarcadores desde las columnas
3. Enviar un loteEn paralelo, marcado con la campaña
4. Mantener el ritmoAl menos un segundo por lote

Una caída nunca envía dos veces. Una campaña que quedó a mitad de envío se marca abortada cuando el worker reinicia; nada se reenvía solo.

El worker lee la lista del almacenamiento línea por línea, así que un archivo muy grande usa la misma memoria que uno pequeño. Envía un lote en paralelo, mide cuánto tardó y espera el resto del segundo. El tamaño del lote es el ritmo de envío, y se lee de una tabla de configuración al inicio de cada campaña, así que el equipo lo sube a medida que el dominio se calienta, sin desplegar. La misma tabla tiene una bandera de pausa: al activarla, el worker deja de tomar campañas nuevas. Cada vez que arranca, el worker busca campañas atascadas en “enviando”, algo que solo pasa tras una caída, y las marca abortadas.

Programar sin un servidor esperando

Una regla programada llama a la API cada pocos minutos. Lee el índice de campañas en estado “programada” y lanza la preparación de las que vencen dentro de la siguiente ventana o ya pasaron. Una campaña lanzada para “ahora” se salta la espera y arranca de inmediato. Una llamada fallida se reintenta, y lo que se pierda se toma en la siguiente ejecución, porque la fuente de verdad es el estado, no el temporizador.

Preparar una lista

El trabajo de preparación descarga la lista, la copia a su propia ubicación y la registra como una tabla cuyas columnas salen del encabezado del archivo. Eso es lo que permite que un reporte luego cruce los eventos de cada destinatario con cualquier columna de la lista, como un número de cliente. Solo entonces la campaña entra a la cola. Si la preparación falla, la campaña se marca fallida y nunca se encola.

De eventos a cifras

Cada pocas horas un trabajo programado corre una consulta SQL sobre una ventana reciente de días y cuenta, por campaña, envíos, entregas, rebotes, quejas, retrasos de entrega, aperturas, clics y desuscripciones, totales y únicos, y los escribe en el registro de la campaña. La consulta nombra las particiones de día que necesita, así que solo recorre los días en que una campaña pudo tener eventos. Los reportes por destinatario y los enlaces más clicados se construyen bajo demanda de la misma forma, se escriben en un archivo y se entregan con un enlace de descarga temporal.

Decisiones

Pregunta	Opciones	Elegimos	Por qué
Dónde corren los envíos	Funciones; un worker en contenedor alimentado por una cola	Un worker en contenedor, una campaña a la vez	Una campaña grande dura más que una función; un solo worker da un ritmo exacto
Qué tan rápido enviar	Lo más rápido posible; fijo en el código; una tabla de configuración	Tabla de configuración, leída por campaña	Subirlo durante el calentamiento sin desplegar
Cómo llegan los archivos	Por la API; enlaces de carga directa con vencimiento	Enlaces de carga directa	La API nunca maneja archivos grandes
De dónde salen las métricas	Un webhook por evento hacia una base de datos; archivo de eventos y SQL	Archivo de eventos, consultado de forma programada	Sin una ruta de escritura por evento que escalar; se paga por consulta
Tras una caída a mitad de envío	Reanudar donde quedó; marcarla y que decida una persona	Marcarla abortada	Nunca arriesgar el mismo correo dos veces
Red	Subredes privadas detrás de un NAT; subredes públicas sin entrada	Subredes públicas, sin puertos de entrada	Un NAT cobra cada hora; las tareas solo llaman APIs de la nube

Protecciones

• Seguridad. Las listas y plantillas se suben con enlaces que vencen en menos de una hora, la cola está cifrada en reposo y los contenedores no aceptan conexiones entrantes.
• Mínimo privilegio. Cada componente recibe sus tablas, su cola y el almacenamiento de archivos de forma explícita en el código de infraestructura; nada se configura a mano en la consola.
• Costo. Tablas y funciones con cobro por solicitud, trabajos que solo corren mientras hay algo que hacer, sin NAT, logs que vencen tras un período definido y consultas que solo recorren los días que necesitan.
• Confiabilidad. Una preparación fallida marca la campaña como fallida en lugar de encolarla, las llamadas del programador se reintentan, y una caída a mitad de envío termina en “abortada”, nunca en un reenvío silencioso.
• Operación. Una bandera de pausa detiene los envíos sin desplegar, y el mismo código despliega un stack aislado por unidad de negocio, cada uno en su propia cuenta.

Modos de falla

Qué falla	Qué pasa
El worker se cae a mitad de una campaña	Al reiniciar, la campaña se marca abortada; nada se reenvía solo
Falla la preparación	La campaña se marca fallida y nunca se encola
El servicio de correo rechaza una dirección	El error queda en el log con la campaña; el lote sigue
Falla una llamada del programador	Se reintenta; la campaña sigue programada para la siguiente ejecución
Falla una consulta de métricas	El trabajo registra el error; las campañas conservan sus cifras anteriores
Algo se ve mal a mitad de envío	Se activa la pausa; el worker deja de tomar campañas

Compromisos, y cuándo no usar esto

Un solo worker envía una campaña a la vez, así que una segunda campaña espera en la cola; es el precio de un ritmo de envío exacto. La entrega es como máximo una vez: una caída aborta la campaña, y reanudar desde el último destinatario enviado no está construido. Un envío individual fallido se registra, no se reintenta. Las métricas se actualizan cada pocas horas, no en vivo. La API se protege con un token compartido y está pensada para un front end interno de confianza; para exponerla más, ponle un ingreso de verdad delante. Y esto no es un editor ni una herramienta de recorridos: si tu equipo diseña campañas de forma visual o dispara correos uno a uno, una plataforma de mercadeo alojada encaja mejor.

Qué mediríamos

• Ritmo de envío sostenido por worker, frente al ritmo configurado.
• Tiempo entre la hora programada de una campaña y su primer correo.
• Tasas de rebote y de queja por campaña, durante y después del calentamiento.
• Proporción de envíos rechazados por el servicio de correo.
• Demora entre un evento y su aparición en la campaña.
• Costo de un refresco de métricas y de un reporte por destinatario.
• Costo mensual de operación por unidad de negocio, con y sin campañas.