ADR-002: Base de Datos por Dominio
Estado: Aceptada
Fecha: 2026-05-18
Autor: Equipo de Arquitectura
Contexto
La plataforma tiene multiples dominios de negocio (Flow, Lending, Sign, Subject) que requieren persistencia de datos. Necesitamos definir la estrategia de aislamiento de datos que balancee seguridad, autonomia de equipos y costos operativos.
Las opciones evaluadas fueron:
- Base de datos compartida: todos los servicios usan la misma base con esquemas separados.
- Esquema por servicio: una base de datos, un esquema por servicio.
- Base de datos por dominio: cada dominio tiene su propia base dentro de un cluster compartido.
- Clusters separados: cada dominio tiene su propio cluster Aurora.
Decision
Adoptar el modelo de base de datos por dominio dentro de un cluster Aurora compartido. Cada servicio tiene:
- Su propia base de datos logica (
imagy_flow,imagy_lending,imagy_sign,imagy_subject) - Su propio usuario de base de datos con permisos restringidos
- Politicas de Row-Level Security (RLS) para aislamiento multi-tenant
Alternativas Consideradas
| Alternativa | Pros | Contras |
|---|---|---|
| Base de datos compartida con esquemas | Menor costo, queries cross-domain faciles | Acoplamiento, riesgo de acceso cruzado, migraciones coordinadas |
| Clusters completamente separados | Maximo aislamiento, escalado independiente | Costo significativamente mayor, complejidad operativa |
| Base de datos por dominio en cluster compartido (elegida) | Aislamiento logico, costo controlado, autonomia de equipos | Sin queries cross-DB directos |
Consecuencias
Positivas
- Aislamiento logico completo entre dominios sin el costo de clusters separados
- Cada equipo es dueno de su esquema y puede evolucionar independientemente
- Las migraciones de un dominio no afectan a otros
- RLS garantiza que un tenant nunca vea datos de otro
- Un solo cluster simplifica backups, monitoreo y failover
Negativas
- No es posible hacer queries cross-database directamente (se deben usar APIs o eventos)
- Compartir el cluster significa compartir recursos de computo (mitigado con Aurora Serverless v2)
- Requiere disciplina para no crear dependencias directas entre bases
Riesgos
- Un dominio con carga excesiva podria afectar el rendimiento de otros (mitigado con connection pooling y limites por usuario)
- La complejidad de RLS puede introducir bugs de seguridad si no se prueba exhaustivamente