Lector de Correo Multi-Proveedor
Captura e ingesta automatizada de comprobantes fiscales enviados por correo.
9 de septiembre de 2026
Contexto
Proveedores envían documentos tributarios electrónicos como adjuntos a través de Gmail, Microsoft 365 y Yahoo Mail. El sistema necesita monitorear múltiples cuentas y proveedores de correo de forma continua.
Problema
Cada proveedor de correo expone una API distinta (OAuth, protocolos de sincronización, límites de tasa), y no todos los correos entrantes contienen comprobantes válidos: hay que filtrar ruido antes de procesar y almacenar archivos.
Decisión de arquitectura
- Plataforma SaaS multi-tenant: una sola implementación sirve a todas las empresas clientes.
- Adaptador por proveedor (Gmail, Microsoft Graph, Yahoo) detrás de una interfaz común de ingesta de correo.
- Pipeline de filtrado que descarta correos sin adjuntos relevantes antes de tocar almacenamiento.
- Guardado de archivos desacoplado del origen de correo, para poder añadir proveedores sin tocar el almacenamiento.
- Una sola base de datos PostgreSQL compartida, con Row-Level Security (RLS) para aislar los datos de cada tenant a nivel de fila.
- Idempotencia por message-id: cada correo se identifica por el ID que entrega la sincronización o la notificación webhook, evitando procesarlo dos veces.
- Reintentos con Polly en las llamadas HTTP a los proveedores; si el fallo persiste, el mensaje se registra en una tabla dead-letter en PostgreSQL en vez de perderse.
- Rate limiting propio (global y por usuario) implementado en C#, con el estado de peticiones por ventana de tiempo persistido en base de datos, para que un tenant no agote la cuota de otro.
- Rotación de secretos vía Key Vault, con una instancia separada por ambiente.
- Observabilidad con .NET Aspire y OpenTelemetry: correlation-id de extremo a extremo, ingestado a Seq (alternativa evaluada: Azure Application Insights, de pago).
- Retención de archivos configurable por usuario, en vez de una política fija global.
Compensaciones
Adaptadores por proveedor vs. cliente IMAP genérico
Más código de mantenimiento a cambio de aprovechar OAuth y webhooks nativos de cada proveedor, más confiables que polling IMAP.
Base de datos compartida con RLS vs. base de datos por tenant
Una sola base reduce costo operativo y simplifica migraciones; RLS aplica el aislamiento a nivel de motor de base de datos en vez de confiar solo en la capa de aplicación.
PostgreSQL vs. MongoDB para el contenido de los documentos
El sistema captura y almacena los adjuntos como archivos, sin leer ni estructurar el contenido del comprobante fiscal. Si esa lectura estructurada fuera un requisito, MongoDB encajaría mejor: el comprobante ya es JSON y se guardaría tal cual, sin mapearlo a un esquema relacional.
Un solo nodo VPS en producción vs. clúster de alta disponibilidad
Producción corre en un único nodo VPS, con un nodo de staging separado. Es una restricción conocida de escalamiento, aceptada por simplicidad operativa mientras la carga no lo justifique.
Diagrama de arquitectura
¿Cómo se generan estos diagramas? Con archify
Resultados
- Ingesta continua desde tres proveedores de correo sin intervención manual.
Comentarios