SaaS en nube propia: la arquitectura de celdas

Estado honesto

El modelo de celdas, el gateway multi-institución, el clonado anonimizado del sandbox y el alta automatizada ya están implementados. Hoy existe una sola celda de demostración, levantada con el procedimiento de alta y con datos ficticios: ninguna institución real corre todavía en una celda. La nube propia sobre servidores físicos (un clúster de tres nodos con almacenamiento replicado y un sitio alterno) es hoja de ruta: el diseño está listo y la infraestructura está por adquirir. «Implementado» en esta Academy significa «en operación en el entorno de demostración», nunca «con bancos reales».

El problema: muchos bancos, un solo proveedor

Ofrecer el core como servicio tiene una trampa. La forma barata es poner a todos los bancos en una sola base de datos y separarlos con una columna que diga «este registro es del banco A». Funciona hasta el día en que una consulta olvida filtrar por esa columna: entonces el banco A ve los clientes del banco B. Y cuando el regulador pide «entrégame tu base de datos», no hay una base que entregar, sino un pedazo de una base compartida.

Una analogía: el edificio de apartamentos

Un banco compartido es una casa donde varias familias duermen en el mismo cuarto y se reparten las gavetas con etiquetas. Una celda es un apartamento: cada familia tiene su puerta, su llave y sus servicios, aunque compartan la recepción del edificio. La recepción (el gateway) sabe a qué apartamento va cada visitante y no le abre otra puerta.

La idea: una celda por institución

En FINORA cada institución (un banco o una fintech) vive en su propia celda: un FINORA Core, su base PostgreSQL y su caché Redis, con su red, sus volúmenes, sus secretos y sus límites de CPU y memoria. Nada de eso se comparte con otra institución.

flowchart TB
  I[Internet] --> B[Borde: TLS]
  B --> G["Gateway multi-institución<br/>token · institución · límites · idempotencia"]
  G --> C1["Celda Banco Demo<br/>core + base + caché"]
  G --> C2["Celda Fintech Demo<br/>core + base + caché"]
  G --> C3["Celda Banco Demo (sandbox)<br/>copia anonimizada"]
  L[Emisor de licencias] -. llaves por módulo .-> C1
  L -. llaves por módulo .-> C2
  L -. llaves por módulo .-> C3

Se eligió una celda por institución, y no un core compartido, por tres razones:

1. Aislamiento real. No hay consulta que pueda cruzar bancos: cada core solo conoce su base.
2. Entrega al regulador. Si el regulador o el propio banco piden su base, es un respaldo de una sola base.
3. Actualización por oleadas. Se actualiza una celda, se observa y luego se actualizan las demás.

El costo es memoria: cada core es un proceso completo. Por eso la celda declara sus límites de recursos y se dimensiona por plan.

El gateway: la recepción del edificio

Todas las integraciones entran por el gateway (https://<su-gateway>/v1). En cada petición:

• Identifica a la institución por el subdominio o por la cabecera X-Finora-Tenant. Si ambos vienen y no coinciden, rechaza la petición.
• Ata el token a la institución. Un token emitido para una institución no sirve en otra: responde 403 TENANT_CRUZADO. Una institución suspendida responde 423.
• Habilita solo los dominios contratados (clientes, depósitos, préstamos, contabilidad, divisas, licencias, webhooks, eventos, configuración). Un dominio fuera del plan responde 403 MODULO_NO_HABILITADO.
• Enruta al core de esa celda con la credencial propia de esa celda, que nunca se escribe en el registro de instituciones: el registro solo nombra la variable que la contiene.

El registro de instituciones es un archivo que el gateway relee solo cuando cambia: dar de alta una institución no reinicia el gateway.

El sandbox: producción y pruebas, separados de verdad

Cada institución puede tener un sandbox: otra celda, con otra base y otro core, nunca el mismo que producción. Se pide por el subdominio de sandbox o con la cabecera X-Finora-Environment: sandbox. El token lleva el ambiente dentro: un token de sandbox usado contra producción, o al revés, responde 403 ENTORNO_CRUZADO.

El sandbox se llena con una copia anonimizada de la base de producción:

Paso	Qué pasa
1. Copia	Se restaura un respaldo de la base de origen en una base temporal con nombre aleatorio: ningún core puede conectarse a ella mientras todavía tiene datos reales.
2. Anonimización	Nombres, documentos, cuentas y contactos se reescriben de forma determinista: el mismo valor original da el mismo valor nuevo en todas las tablas, así que las relaciones siguen cuadrando.
3. Purga	En la misma transacción se borran las llaves de API, las sesiones y las autorizaciones: la copia no trae ninguna credencial.
4. Publicación	Solo si todo salió bien, la base temporal toma el nombre del sandbox. Ante cualquier error, la temporal se elimina.

Lo que la anonimización no cubre

Los textos libres de movimientos y asientos (la descripción que alguien escribió a mano) pueden contener nombres y no se reescriben. Los campos cifrados con las llaves de producción se anulan, porque el sandbox usa sus propias llaves.

El alta de una institución en un solo procedimiento

Dar de alta una institución nueva toca tres sistemas: la celda, el emisor de licencias y el gateway. Un solo procedimiento los recorre en orden, y por defecto solo muestra el plan sin tocar nada:

flowchart LR
  A["a) Celda<br/>configuración y secretos propios"] --> B["b) Licencias<br/>instalación · suscripción · llaves"]
  B --> C["c) Arranque<br/>base de referencia · core sano"]
  C --> D["d) Credencial del gateway<br/>ante el core de la celda"]
  D --> E["e) Registro del gateway<br/>la institución queda enrutada"]

Es idempotente: si lo vuelves a ejecutar no regenera secretos, no crea una segunda suscripción, repite la emisión con la misma clave de idempotencia y no duplica la entrada del gateway. Los secretos nunca se imprimen ni viajan en la línea de órdenes: quedan en archivos con permisos restringidos dentro de la celda. El paso a paso está en Da de alta una institución y su sandbox.

También en el centro de datos del banco

La celda no depende de dónde corra. El mismo core se instala en el centro de datos del banco (on-premise) con el instalador de la suite (Cómo se instala la suite): entonces hay una sola institución y el gateway trabaja con un único core.

La nube propia sobre servidores físicos (hoja de ruta)

El diseño de la nube propia prevé un clúster de tres nodos con almacenamiento replicado, un servidor de respaldos con retención escalonada, red y cortafuegos duplicados y un sitio alterno con réplica de la base. Puede ubicarse en el país cuando el regulador lo exija. Hoy es hoja de ruta: nada de esto está comprado ni instalado, y por eso ninguna celda de una institución real corre todavía.

Siguientes pasos

• Suscripción y licencias por módulo: qué recibe cada celda en el paso de licencias.
• Da de alta una institución y su sandbox: el procedimiento, en modo de prueba y aplicado.
• El mapa de la suite: dónde encajan el gateway y el emisor.