Más allá de monolitos
y microservicios.

01 / La elección de arquitectura

Monolitos y microservicios resuelven problemas distintos.

Un monolito empaqueta una aplicación como una única unidad desplegable. Puede ser modular, estar bien probado y replicarse detrás de un balanceador de carga. Su atractivo es práctico: llamadas locales, depuración sencilla y menos componentes. Sus limitaciones suelen aparecer en torno a las versiones compartidas, los límites de responsabilidad o unas necesidades de recursos desiguales.

Los microservicios dividen una aplicación en servicios que se despliegan de forma independiente. Son útiles cuando los dominios y los equipos necesitan sus propios ciclos de versiones, políticas de escalado o límites operativos. Esa independencia tiene un coste: llamadas de red, contratos versionados, observabilidad, gestión de fallos y, a menudo, coherencia entre almacenes de datos separados.

Ninguno es automáticamente más rápido ni más escalable. Un monolito bien diseñado puede atender una gran carga de trabajo. Un sistema de microservicios mal particionado puede distribuir sus cuellos de botella y hacerlos más difíciles de ver.

La distinción importa porque distribuir el despliegue y modularizar el negocio son decisiones separadas. Se pueden tener módulos sin servicios separados, y muchos servidores sin fragmentar el modelo lógico de la aplicación.

02 / Un único modelo lógico

Acercar la base de datos y el backend.

Cygnus es la base prevista de lenguaje, base de datos y backend de NatusAI. El diseño reúne la lógica de aplicación tipada, los datos persistentes y las funciones expuestas en un entorno coherente. En lugar de mantener una correspondencia separada en cada frontera, los desarrolladores trabajan con objetos conectados y con las funciones que actúan sobre ellos.

Esto es especialmente relevante para un gemelo digital o una aplicación operativa. Un buque, un edificio o un activo industrial tiene identidad, relaciones, ubicación, mediciones, documentos e historial. Repartir cada vista en un sistema sin relación con los demás obliga a reconstruir conexiones que ya existen en el negocio.

Un modelo unificado pretende preservar esas conexiones. También da al entorno de ejecución más información sobre los datos, las consultas y la ejecución: información que puede servir de base para futuras decisiones de ubicación y coordinación.

Un modelo para la aplicación.
Más opciones sobre dónde se ejecuta.

Es un principio de diseño, no la promesa de que cualquier carga de trabajo escale de forma transparente. Las claves de partición, los patrones de consulta, los límites de las transacciones y la latencia siguen influyendo en cómo debe construirse una aplicación.

03 / Cuatro formas de crecer

Escalar peticiones y datos como necesidades distintas.

«Tenemos que escalar» puede significar más peticiones simultáneas, un conjunto de datos mayor, mejor disponibilidad… o las tres cosas. La replicación y el sharding abordan partes distintas de ese problema. El siguiente explorador ilustra la dirección de diseño distribuido de Cygnus; no es un clúster en funcionamiento ni una función de despliegue publicada.

Empezar en un nodo

El perfil previsto de la v1 empieza con un servidor. El código de la aplicación y los datos residen juntos, lo que hace accesible el primer despliegue. Las copias de seguridad, la recuperación, los permisos y los límites de recursos siguen formando parte de una operación responsable.

Replicar para ganar redundancia y capacidad de peticiones

En el futuro modelo distribuido, varios nodos podrían llevar el mismo código y una copia completa del conjunto de datos. Esto puede crear más puntos desde los que atender las peticiones adecuadas y permitir que el sistema tolere el fallo de algunos nodos. El resultado depende del enrutamiento, el retardo de replicación, las garantías de coherencia y qué operaciones pueden ejecutarse en qué réplicas.

Particionar para ganar capacidad de datos

Cuando el conjunto de datos supera la capacidad de un servidor, añadir copias completas no resuelve la limitación de almacenamiento. El sharding reparte los datos entre nodos. Una carga de trabajo podría particionarse por geografía, rango temporal o rango de claves. Las consultas que cruzan esas particiones necesitan enrutamiento y, a veces, ejecución distribuida.

Una ilustración sencilla de capacidad: 30 TB de datos lógicos necesitan al menos ocho servidores de 4 TB cada uno, antes de contar réplicas, índices, margen operativo u otros sobrecostes. Es aritmética, no una medición de capacidad de Cygnus.

Combinar ambos

Cada shard puede tener sus propias réplicas. Los shards aportan capacidad de datos agregada; las réplicas añaden redundancia y oportunidades para atender peticiones. Esta topología combinada suele ser lo que se imagina cuando se piensa en una base de datos distribuida en una flota de servidores.

Crecer y reducirse según la demanda

La dirección a más largo plazo es automatizar estas decisiones en función de políticas de carga de trabajo: añadir capacidad cuando crece la demanda, trasladar la ejecución junto a los datos que necesita y liberar capacidad cuando la demanda baja. El objetivo es preservar el modelo lógico de la aplicación aunque cambie la ubicación.

Para reducir capacidad, primero hay que vaciar el trabajo y reubicar o conservar con seguridad las copias de datos necesarias. La planificación, el reequilibrio, la coherencia y la recuperación necesitan reglas explícitas y cualificación. El escalado automático hacia fuera y hacia dentro son objetivos de diseño futuros del clúster, fuera de la v1 prevista para un solo servidor.

04 / La responsabilidad del entorno de ejecución

Llevar la coordinación a la plataforma.

La experiencia prevista de Cygnus mantiene una única base de código de la aplicación y una única base de datos lógica a medida que evoluciona el despliegue. La distribución gestionada por el entorno de ejecución asumiría la ubicación, el enrutamiento, la replicación y la mecánica de coordinar los nodos participantes.

Esa mecánica no desaparece. Las redes introducen latencia y particiones. Las actualizaciones necesitan reglas de coherencia. Las transacciones que abarcan varios shards necesitan un protocolo definido. La recuperación debe saber qué se confirmó, y el reequilibrio debe evitar perder la titularidad de los datos mientras se mueven.

La oportunidad está en implementar estas responsabilidades una sola vez en la plataforma, con contratos explícitos y herramientas de operación, en lugar de que cada aplicación construya su propia versión. La aplicación sigue necesitando límites adecuados a su carga de trabajo.

05 / Los datos a lo largo del tiempo

Un modelo conectado necesita memoria.

Muchas preguntas de negocio tienen una dimensión temporal, aunque nadie la mencione. ¿Dónde estaba este activo antes de un incidente? ¿Qué organización lo controlaba entonces? ¿Qué sabía el sistema cuando hizo esa recomendación?

El diseño de Cygnus conecta relaciones de grafo, datos geoespaciales, vectores, tripletas, series temporales y búsqueda de texto completo dentro de la misma base lógica. Son formas de explorar un objeto, no definiciones separadas de lo que ese objeto es.

Historial para los datos, y procedencia para la IA

Los datos temporales pueden describir cómo cambian un activo, sus lecturas o sus relaciones. Una respuesta histórica de IA requiere algo más: depende también de los documentos fuente, los embeddings, la configuración de recuperación, la versión del modelo y el prompt utilizados para generarla.

Conservar un historial de datos no conserva automáticamente cada índice vectorial ni reproduce una respuesta pasada de un modelo. Un buen diseño conecta esas versiones y registra su procedencia de forma deliberada, para que una respuesta pueda remitir a la evidencia y al contexto que la respaldaron.

Una base para aplicaciones y herramientas

Las capacidades previstas de MCP nativo y de chat ofrecen formas de exponer funciones permitidas y de consultar el conocimiento conectado. Una herramienta o una interfaz conversacional debería trabajar con el mismo modelo y la misma política de acceso que la aplicación. Así, una consulta histórica puede preguntar por un momento elegido y explicar qué evidencia y qué configuración de IA están disponibles para esa respuesta.

Aquí es donde un backend unificado se convierte en algo más que un despliegue más sencillo: puede ofrecer una base compartida para los datos operativos, el historial del negocio y el trabajo asistido por IA.

06 / Elegir los límites

Mantener la arquitectura alineada con el trabajo.

Los microservicios siguen siendo útiles cuando los justifican equipos independientes, límites de seguridad distintos o requisitos operativos diferentes. Un monolito modular sigue siendo útil cuando un despliegue compartido mantiene productivo al equipo. La dirección de Cygnus añade otra opción: un modelo unificado de aplicación y datos, con la distribución gestionada a más profundidad en el entorno de ejecución.

La elección correcta empieza por la carga de trabajo. ¿Qué peticiones predominan? ¿Con qué rapidez deben ser visibles las actualizaciones? ¿Qué datos van juntos? ¿Qué ocurre durante un fallo de red? ¿Qué responsabilidades necesitan una titularidad independiente?

Nuestra ambición es que los desarrolladores dediquen más tiempo a esas decisiones relevantes y menos a reconstruir las conexiones entre sus herramientas. Empiece con un modelo coherente. Mantenga intactas las relaciones del negocio. Amplíe el despliegue físico cuando la carga de trabajo y la plataforma estén preparadas.