Beyond monoliths
and microservices.

01 / The architecture choice

Monoliths and microservices solve different problems.

A monolith packages an application as one deployable unit. It can be modular, carefully tested and replicated behind a load balancer. Its attraction is practical: local calls, straightforward debugging and fewer moving parts. Its limitations often emerge around shared releases, ownership boundaries or uneven resource needs.

Microservices split an application into independently deployable services. They are useful when domains and teams need their own release cycles, scaling policies or operational boundaries. That independence comes with work: network calls, versioned contracts, observability, failure handling and often consistency across separate data stores.

Neither is automatically faster or more scalable. A well-designed monolith can serve a large workload. A poorly partitioned microservice system can distribute its bottlenecks and make them harder to see.

The distinction matters because deployment distribution and business modularity are separate decisions. You can have modules without separate services; you can have many servers without fragmenting the application’s logical model.

02 / One logical model

Bring the database and backend closer together.

Cygnus is NatusAI’s planned language, database and backend foundation. The design brings typed application logic, persistent data and exposed functions into one coherent environment. Instead of maintaining a separate mapping at every boundary, developers work with connected objects and the functions that act on them.

That is especially relevant to a digital twin or an operational application. A vessel, building or industrial asset has identity, relationships, location, measurements, documents and a history. Splitting each view into an unrelated system means rebuilding connections that already exist in the business.

A unified model aims to preserve those connections. It also gives the runtime more information about data, queries and execution—information that can support future placement and coordination decisions.

One model for the application.
More options for where it runs.

This is a design principle, not a promise that every workload scales transparently. Partition keys, query patterns, transaction boundaries and latency still influence how an application should be built.

03 / Four ways to grow

Scale requests and data as distinct needs.

“We need to scale” can mean more simultaneous requests, a larger dataset, better availability—or all three. Replication and sharding address different parts of that problem. The following explorer illustrates the Cygnus distributed design direction; it is not a live cluster or a released deployment feature.

Start on one node

The planned v1 profile starts with one server. Application code and data live together, keeping the first deployment approachable. Backups, recovery, permissions and resource limits remain part of operating it responsibly.

Replicate for redundancy and request capacity

In the future distributed model, several nodes could carry the same code and a complete copy of the dataset. This can create more places to serve suitable requests and allow the system to tolerate some node failures. The result depends on routing, replication lag, consistency guarantees and which operations can execute on which replicas.

Shard for data capacity

When the dataset outgrows a server, adding full copies does not solve the storage constraint. Sharding divides the data across nodes. A workload might partition by geography, time range or key range. Queries that cross those partitions need routing and, sometimes, distributed execution.

A simple capacity illustration: 30 TB of logical data needs at least eight servers with 4 TB each, before replicas, indexes, operational headroom or other overhead. That is arithmetic, not a Cygnus capacity measurement.

Combine the two

Each shard can have replicas of its own. Shards supply aggregate data capacity; replicas add redundancy and opportunities to serve requests. This combined topology is often what people mean when they picture a database distributed across a fleet.

Grow and shrink with demand

The longer-term direction is to automate these choices around workload policies: add capacity when demand grows, move execution with the data it needs, and release capacity when demand falls. The aim is to preserve the application’s logical model as placement changes.

Scaling down must first drain work and safely relocate or retain the required data copies. Scheduling, rebalancing, consistency and recovery need explicit rules and qualification. Automatic scale-out and scale-in are future cluster design goals, outside the planned single-server v1.

04 / The runtime’s responsibility

Move coordination into the platform.

The intended Cygnus experience keeps one application codebase and one logical database as the deployment evolves. Runtime-managed distribution would take on placement, routing, replication and the mechanics of coordinating participating nodes.

Those mechanics do not disappear. Networks introduce latency and partitions. Updates need consistency rules. Transactions that span shards need a defined protocol. Recovery must know what was committed, and rebalancing must avoid losing ownership of data while it moves.

The opportunity is to implement these responsibilities once in the platform, with explicit contracts and operating tools, instead of making each application assemble its own version. The application still needs boundaries that fit its workload.

05 / Data through time

A connected model needs a memory.

Many business questions include a time dimension, even when nobody says it aloud. Where was this asset before an incident? Which organisation controlled it then? What did the system know when it made that recommendation?

The Cygnus design connects graph relationships, geospatial data, vectors, triples, time series and full-text search within the same logical foundation. These are ways to explore a subject, rather than separate definitions of what that subject is.

History for data—and provenance for AI

Temporal data can describe how an asset, its readings or its relationships change. A historical AI answer requires more. It also depends on the source documents, embeddings, retrieval configuration, model version and prompt used to produce it.

Retaining a data history does not automatically retain every vector index or reproduce a past model response. A useful design connects those versions and records their provenance deliberately, so an answer can point back to the evidence and context that supported it.

One foundation for applications and tools

The planned native MCP and chat capabilities provide ways to expose permitted functions and query connected knowledge. A tool or conversational interface should work against the same model and access policy as the application. A historical query can then ask about a chosen time, while explaining which evidence and AI configuration are available for that answer.

This is where a unified backend becomes more than a simpler deployment story: it can provide a shared foundation for operational data, business history and AI-assisted work.

06 / Choosing the boundaries

Keep the architecture aligned with the work.

Microservices remain useful when independent teams, distinct security boundaries or different operating requirements justify them. A modular monolith remains useful when a shared deployment keeps the team productive. Cygnus’s direction adds another option: a unified application and data model with distribution managed deeper in the runtime.

The right choice starts with the workload. Which requests dominate? How quickly must updates become visible? Which data belongs together? What happens during a network failure? Which responsibilities need independent ownership?

Our ambition is to let developers spend more time on those meaningful decisions and less time rebuilding the connections between their tools. Start with a coherent model. Keep the business relationships intact. Grow the physical deployment when the workload and the platform are ready.