Arquitectura de Datos
Arquitectura de datos (OLTP / reportes / analítica) y dashboards generativos con Flai
Datos rápidos sin afectar la operación + dashboards a pedido
1. ¿Flai puede crear dashboards a medida? Sí (BI generativo)
Lo que pidió Rosa ("armar mi propio dashboard, como una tabla dinámica") es exactamente esto:
- Pides en lenguaje natural → Flai arma la definición (no SQL crudo expuesto) → se renderiza y se guarda como dashboard del tenant (reusable, compartible por rol).
- Es config-as-data: el dashboard es configuración guardada, igual que los rubros y los feature flags.
- Hoy el BI de la demo es estático; esto lo vuelve dinámico y generado por IA.
2. Tu instinto es correcto: separar lo transaccional de lo analítico
Sí conviene no mezclar la operación con los reportes pesados. Pero no son necesariamente 3 servidores de base de datos desde el día 1. Son 3 capas (que al inicio viven en una base + réplica, y se separan cuando el volumen lo pide):
| Capa | Para qué | Tecnología (etapa) |
|---|---|---|
| 1. Transaccional (OLTP) | Operar: ventas, inventario, reparto (escrituras rápidas) | Postgres primario (tenant_id + RLS) |
| 2. Reportes usuales (lectura) | Reportes y tableros frecuentes sin frenar la operación | Réplica de lectura + vistas materializadas |
| 3. Analítica / IA (OLAP) | Reportes pesados y los que pide Flai (cruces, históricos) | Vistas materializadas al inicio → DWH (ClickHouse/BigQuery/DuckDB) al escalar |
3. ¿3 bases separadas ya? No — por etapa
| Etapa | Recomendación |
|---|---|
| Piloto | Una Postgres (Supabase) + vistas materializadas para reportes. Simple y barato. |
| Crecimiento | Agregar réplica de lectura: Flai y los reportes consultan la réplica → no afectan la operación. |
| Escala | Agregar DWH (ClickHouse/BigQuery) alimentado por CDC/ETL para analítica pesada. |
Crear 3 bases ahora = más costo y operación sin usuarios todavía. Mejor una capa lógica que se separa cuando duela. La app no cambia: solo cambia a dónde apunta cada tipo de consulta.
4. Cómo la IA NO afecta la operación
- Flai lee de la réplica/reportes (capa 2/3), no de la base transaccional → la operación (facturar, despachar) nunca se frena por un reporte.
- Flai escribe solo en OLTP y solo vía tools con permiso (marcar entrega, registrar venta) — tenant-scoped y auditado.
- Consultas frecuentes con caché; cuotas por tenant (ver [[25-flai-consumo-whatsapp]]).
5. Aislamiento por tenant (en todas las capas)
tenant_iden cada tabla, vista y consulta + RLS.- El MCP (uno solo, multi-tenant) inyecta el
tenant_iden cada llamada → Flai jamás cruza datos entre empresas, ni en reportes ni en dashboards. Ver [[20-roadmap-backend]] §4.1.
6. Plan
- OLTP (Postgres/Supabase) + vistas materializadas para reportes (piloto).
- Dashboards generativos con Flai (definición guardada por tenant).
- Réplica de lectura cuando crezca el uso de reportes/IA.
- DWH + CDC al escalar (analítica pesada, cross-negocio).
Relacionado: [[24-roadmap-general]] · [[26-despliegue-costos-admin]] · [[17-plataforma-core-verticales]].