Cada envío respeta el consentimiento, en decenas de millones de clientes

Qué es

Una plataforma de consentimiento, en producción para decenas de millones de clientes. Al frente, un centro de preferencias al que tus clientes llegan desde un enlace en cualquier correo, sin contraseña. Detrás, una sola fuente de verdad sobre quién quiere qué, reconstruida cada noche en las listas que leen tus envíos. Y un pequeño backoffice donde tu equipo carga archivos de supresión de otros canales, exporta listas y consulta el historial de cualquier correo.

El problema que resuelve

Con decenas de millones de clientes, el consentimiento es un problema de datos, no una página. La elección de un cliente queda en un sistema mientras tus campañas leen otro. Una solicitud que llegó por teléfono se queda en una hoja de cálculo hasta que alguien la carga a mano. Cada error se convierte en una queja, en un reporte de spam que perjudica la entrega de todos tus demás correos y, en sectores regulados, en una pregunta de cumplimiento que nadie quiere responder.

También cuesta tiempo por dentro. Mercadeo no ve quién está suprimido ni por qué, soporte no puede decir cuándo alguien se desuscribió, y el sistema viejo que nadie quiere tocar guarda la única copia de la verdad.

Qué obtienes

• Desuscripciones que se cumplen: la elección del cliente llega a cada campaña sin que nadie la copie a mano.
• Solicitudes de supresión por teléfono, oficinas o aliados cargadas desde un archivo en minutos, con cada línea inválida reportada.
• Una respuesta clara a “¿cuándo y por qué se suprimió este correo?” para cualquier cliente.
• Listas para envío siempre completas: una reconstrucción termina o se mantiene la anterior.
• Fuera de la base de datos heredada sin perder historia: cada desuscripción y rebote anterior se conserva.

Cómo lo entregamos

Partimos de lo que tienes: dónde viven hoy las preferencias, quién las lee y qué necesita el lado de envío. Migramos los datos existentes al nuevo sistema, operamos ambos en paralelo, los comparamos lista por lista y hacemos el cambio cuando las diferencias están explicadas. Te acompañamos las primeras semanas de uso real.

¿Es para ti?

Encaja si envías a listas de decenas de millones, tienes un sistema heredado con datos de consentimiento y necesitas demostrar qué pasó con cualquier cliente. No es para ti si tu herramienta de email ya maneja bien las preferencias y nada más las lee, o si las listas deben actualizarse en tiempo real en varias herramientas: aquí las listas de envío se actualizan a diario y bajo demanda.

Objetivos de diseño

1. Ningún proceso masivo sobrescribe la elección de un cliente.
2. Los envíos leen una lista completa o la anterior, nunca la mitad de una.
3. Salir de la base de datos heredada no pierde ninguna desuscripción ni ningún rebote.
4. Cada cambio en el consentimiento de una persona se puede rastrear: qué, cuándo, desde dónde y quién.
5. Nada corre, y casi nada cuesta, mientras nadie lo usa.

Arquitectura

1. Personas y entradas

   ClientesEnlace en cualquier correo, sin login

   AdministradoresBackoffice solo por invitación

   Plataforma de campañasCategorías, token de solo lectura

2. Aplicaciones

   API del centro de preferenciasServerless, enlace firmado

   BackofficeIngreso en el servidor

   TrabajosContenedores bajo demanda

3. Fuente de verdad

   PreferenciasUn registro por correo

   Registro de auditoríaCada cambio, consultable

4. Envíos

   SnapshotsUn archivo por lista

   Tablas de consultaSQL sobre los archivos

   Lado de envíoFiltra cada campaña

Cuatro piezas, cada una a la medida de su tráfico. La API del centro de preferencias es serverless: los clientes llegan en ráfagas después de una campaña y luego nada durante horas. Un código firmado y con vencimiento en el enlace del correo identifica a la persona, así que no hay contraseña ni correo en la URL. Las categorías vienen de la plataforma de campañas que mercadeo ya edita, con un token que solo puede listarlas y una caché en dos niveles para que una caída allá no tumbe esta página.

Un registro por correo es la fuente de verdad: las categorías elegidas, si la persona está en la lista global de supresión y si su correo rebotó. A este tamaño (decenas de millones de clientes, millones de ellos en la lista global, y muchas menos suscripciones a categorías), una tabla clave-valor con cobro por solicitud atiende los guardados de clientes y los trabajos masivos sin planear capacidad.

El trabajo masivo corre en contenedores bajo demanda: importaciones, exportaciones, la reconstrucción nocturna y la migración. Una migración de horas no cabe en el límite de tiempo de una función, y nada debería cobrar entre trabajos.

Los envíos leen archivos, no la tabla en vivo. Cada noche, y en cada exportación, los registros se reconstruyen en un archivo por lista, con tablas SQL encima. Filtrar una campaña es una consulta sobre esas tablas, y la tabla en vivo nunca recibe una lectura de la tabla completa en horario laboral.

Cómo resolvemos lo difícil

Qué pasa cuando un cliente guarda

Cada guardado envía todas las casillas, y la línea de auditoría registra qué cambió y cómo quedó la persona. Una regla exigió criterio: quien está en la lista global y ahora marca una categoría dio su consentimiento de nuevo, así que sale de la lista. La excepción es un correo rebotado: sigue suprimido marque lo que marque, porque enviar a un buzón muerto perjudica la entrega de todos los demás. El rebote es un campo permanente del registro, nunca se vuelve a deducir de una fila vieja.

Importar un archivo de otro canal

Las solicitudes por teléfono u oficinas llegan como un archivo simple de correos. El navegador lo sube directo al almacenamiento con un enlace temporal, así que la API nunca maneja los bytes. El trabajo inicia una sola vez, y solo si el archivo de verdad llegó. Reporta duplicados y líneas inválidas con su número en lugar de rechazar todo el archivo. La acción aplica a una lista (la global o una categoría), y quienes ya están en el estado pedido no se tocan.

Migrar desde la base de datos heredada

1. Leer el lado heredadoSesión de solo lectura, por páginas
2. Un registro por correoConserva las filas originales
3. Respetar lo nuevo¿Ya guardó aquí? Se conserva
4. Escribir y compararCoinciden con las tablas viejas

Se detiene antes de hacer daño. Si una repetición fuera a borrar más de una pequeña parte de lo importado, falla y no borra nada.

El lado heredado se lee con una sesión de solo lectura. Las tablas de categorías caben en memoria; la lista global se recorre por correo a un ritmo constante y controlado. Cada registro conserva sus filas originales, así que los archivos reconstruidos coinciden columna por columna con las tablas viejas y se pueden comparar antes del cambio. La migración se puede repetir hasta el cambio, y dos protecciones lo hacen seguro: quien ya guardó en el nuevo centro conserva sus elecciones, y si una repetición fuera a borrar más de una pequeña parte de lo importado, se detiene sin borrar nada.

Publicar las listas

La reconstrucción escribe las filas en archivos temporales, así que la memoria no crece con la tabla. Las tablas de consulta se apuntan a la nueva carpeta solo cuando todos los archivos subieron, y el puntero “más reciente” se escribe al final. Si falla una carga, los lectores siguen con el snapshot anterior.

Decisiones

Pregunta	Opciones	Elegimos	Por qué
Dónde corren los trabajos masivos	Funciones; workers siempre encendidos; contenedores bajo demanda	Contenedores bajo demanda	Trabajos de horas, nada corriendo entre ellos
Cómo leen los envíos las listas	Tabla en vivo; formato de tablas con actualización por fila; archivos + tablas SQL	Archivos, tablas reapuntadas en cada snapshot	Las reconstrucciones completas no necesitan actualizar filas; reapuntar es atómico
De dónde vienen las categorías	Copia de la base de la plataforma de campañas; su API	Su API con token de solo lectura y caché	Una sola fuente que mercadeo ya edita
Ingreso de administradores	Páginas de login alojadas; tokens en el navegador; ingreso en el servidor	En el servidor, sesión en cookies HttpOnly	Ningún token al alcance de los scripts de la página
Historial de una persona	Tabla de historial; líneas de auditoría en los logs	Líneas de auditoría, buscables durante un período de retención definido	Suficiente para responder “qué pasó con este correo”, sin nada nuevo que operar
Protección contra abuso	Firewall de aplicaciones; límites en la aplicación	Límites por correo y por IP, tope de concurrencia	Proporcional para una herramienta interna pequeña

Protecciones

• Seguridad. Backoffice solo por invitación, con dos roles. Ingreso en el servidor, sesión en cookies HttpOnly, Secure y SameSite=Strict, un encabezado propio en cada cambio y una política de seguridad de contenido estricta. Los intentos fallidos se limitan por correo y por IP; el encabezado de IP del cliente que agrega la CDN solo se confía junto con un secreto que ella misma agrega.
• Mínimo privilegio. El token que lee las categorías no puede hacer nada más. Los trabajos solo pueden actualizar sus propias tablas. La base de datos heredada solo se lee.
• Costo. Almacenamiento y funciones con cobro por solicitud, contenedores solo mientras corre un trabajo, snapshots viejos que vencen y el backoffice con un tope estricto de ejecuciones simultáneas, para que una avalancha reciba errores y no una factura.
• Confiabilidad. Las escrituras condicionales protegen las elecciones de los clientes, cada trabajo se puede repetir sin riesgo, los borrados masivos se rechazan y la tabla tiene recuperación a un punto en el tiempo.
• Datos personales. La búsqueda de auditoría es solo para administradores. La página del cliente nunca muestra ni recibe un correo en la URL.

Modos de falla

Qué falla	Qué pasa
La plataforma de campañas se cae	Se sirve el último árbol de categorías en caché; los guardados siguen funcionando
Un trabajo muere a mitad de camino	Su registro queda “en curso”; repetirlo es seguro
Falla una carga al publicar	Los lectores siguen con el snapshot anterior
La lectura de la base heredada vuelve incompleta	La repetición se niega a un borrado masivo y falla de forma visible
Alguien inunda el backoffice	La concurrencia tiene tope; las demás reciben 429
Un despliegue cambia los ids de las categorías	Hay que limpiar las cachés antes y después, o se sirve el árbol viejo por unos minutos

Compromisos, y cuándo no usar esto

Las listas de envío se actualizan a diario y en cada exportación, no en tiempo real; si varias herramientas necesitan una elección en segundos, envíales los cambios directamente. Las desuscripciones por categoría se registran como ausencia de la lista, igual que en las tablas heredadas; no se construye una lista aparte de “se desuscribió de X”. Los rebotes nuevos después de la migración aún no se incorporan (planeado). Sin firewall, un intento lento y distribuido de adivinar contraseñas queda por debajo de los límites; para una herramienta administrativa grande y expuesta al público, agrega uno.

Qué mediríamos

• Tamaño de la lista global y suscripciones a categorías tras la migración.
• Ritmo de la migración, sostenido.
• Tiempo de la reconstrucción nocturna a volumen completo.
• Tiempo de una exportación, de la solicitud a la descarga, a volumen completo.
• Latencia de guardado en el centro de preferencias (p95).
• Costo mensual de operación.
• Diferencias entre las nuevas listas y las tablas heredadas al hacer el cambio.