Arquitectura

Base de datos

PostgreSQL es la única fuente de verdad de negocio: conserva la configuración y los datos de listmonk, los clicks, los bounces y el esquema propio con los eventos de interés.

Resumen

Un único PostgreSQL almacena dos ámbitos: los datos operativos de listmonk (suscriptores, campañas, clicks, bounces) y el esquema propio med_tracking con los eventos de interés registrados por FastAPI.

Entidades y persistencia

ÁmbitoDatos que persisteQuién escribe
Configuración de listmonkSuscriptores, listas, templates y campañas.listmonk
Interacción de emailClicks registrados desde el CTA.listmonk
Feedback de entregaBounces y complaints; estado de blocklist.listmonk
med_trackingEventos de interés confirmado en la landing.FastAPI

Relaciones

Los eventos de interés se asocian a la campaña y al suscriptor mediante los identificadores opacos que viajan desde el email hasta la landing.

Diagrama: Modelo conceptual derivado del flujo (identificadores opacos rid y cid)Diagrama: Modelo conceptual derivado del flujo (identificadores opacos rid y cid)
Modelo conceptual derivado del flujo (identificadores opacos rid y cid)

Modelo conceptual

El diagrama ilustra las relaciones descritas en el flujo (click, interés y bounce por suscriptor y campaña). Los nombres de atributo son representativos, no un esquema físico literal.

Esquema med_tracking

Es el esquema propio de MediNodo, separado de las tablas de listmonk. Almacena los eventos de interés confirmado que registra FastAPI tras validar campaña y suscriptor y aplicar idempotencia.

Escritura

FastAPI

Registra el interés validado e idempotente.

Clave

rid + cid

Asocia el evento a suscriptor y campaña.

Aislamiento

Esquema propio

Separado de los datos operativos de listmonk.

Responsabilidades

  • listmonk escribe suscriptores, campañas, clicks y bounces, y mantiene la blocklist.
  • FastAPI escribe exclusivamente en med_tracking.
  • PostgreSQL conserva los datos de negocio con independencia del borde de Cloudflare.
  • Restic respalda de forma cifrada la base y los uploads de listmonk.

Buenas prácticas

  • Mantener el interés en med_tracking aislado de las tablas de listmonk para acotar responsabilidades.
  • Aplicar restricciones de idempotencia en el registro de interés para evitar duplicados por reintentos.
  • Verificar periódicamente la restauración de las copias cifradas.

Consideraciones

Punto único de datos

Al ser la única fuente de verdad, PostgreSQL concentra el riesgo: su disponibilidad y sus backups son críticos para todo el sistema.