The cell model
A cell is the unit of deployment in System9, a complete instance of the whole platform, running as one coordinated process tree with its own local databases, its own object store, its own service processes, and its own set of cryptographic keys. It is not a worker node waiting on a coordinator; it is a whole platform that happens to be one machine.
Everything else in the architecture is a way of composing cells. Understand the cell and the rest of the topology follows.
The composition property is the one that matters most at scale: every cell contributes its compute, its networking and its storage to the whole. A cell is not a replica of a primary and not a worker awaiting instructions, so joining one to an estate adds all three capacities rather than adding a dependent. A cell in a cloud region, a cell in a plant and a cell on a vessel each add the same three things to the same intelligence, across physical and jurisdictional boundaries, with placement, residency and durability configurable per workload.
What is inside one cell
A single cell is a complete product on its own: catalog, engines, object storage, messaging, identity, audit, and console are all present, with no separate "enterprise edition" and no re-architecture to grow beyond it.
- Its own transactional store. A cell embeds its own databases rather than reaching out to a shared one. State is split across domains, cells and topology, the directory of entities, the catalog of workspaces and data, object storage, sessions, compute, messaging, and query metadata, with strict boundaries between them. Cross-database writes are forbidden; an operation that needs two domains goes through a service sequence that owns the ordering.
- Its own object store. Objects, versions, erasure sets, and retention live on the cell.
- Its own services. A small set of supervised processes runs per cell, identity and security, platform topology and fabric, the data engines and catalog, object storage, messaging, metrics, compute, and the public gateway, started in a fixed dependency order and sharing one common runtime.
- Its own identity. One machine identity, one set of keys. A cell is not itself an entity; it inherits identity through the node it belongs to (see below).
Because the whole platform is present locally, a cell can be a development box, a small sovereign site, or a disconnected tactical node, the same code in every case.
Cells, service groups, nodes, organizations
The hierarchy is physical-first, logical-on-top. Two of these units are physical groupings and two are identities.
| Unit | What it is | An entity? |
|---|---|---|
| Cell | The physical unit of deployment: one process tree, one set of databases, one set of keys, one machine identity. Replication, leasing, and placement all operate at cell level. | No |
| Service group | A grouping of cells for a purpose: an erasure set, a replication group, or a workload boundary. Can span availability zones, regions, and clouds. | No |
| Node | A logical construct that aggregates one or more cells under a single identity and can span physical locations. Where estate-level, roll-up answers live. | Yes |
| Organization | The customer boundary. Organizations own nodes, users, role assignments, and governance domains. | Yes |
The rule that follows, and is upheld throughout the platform: cells and service groups are not entities. A cell inherits identity through its node.
"Tenant" is not System9 vocabulary. Organizations mint nodes; cells make up a node; workspaces and clean rooms are built on a node and run across its cells. The word "multi-tenant" never appears; the scoping words are organization, node, cell, workspace, and clean room.
Workspaces and clean rooms belong to a node
Cells are where compute and storage physically live. Work, though, happens inside a workspace or a clean room, and those belong to the node, not to any one cell. A node's cells are what carry them, so a workspace runs across the cells of its node rather than living inside one of them.
That is why a cell can be rebuilt, replaced or added without a workspace moving: the workspace was never a property of the cell.
- Workspace: the universal ownership and collaboration boundary. Every entity gets one; provisioning creates the workspace record, a dedicated storage namespace, a messaging inbox, an owner membership, and default streams. Members inside a workspace trust each other and have full access. Isolation is between workspaces.
- Clean room: a mutual-distrust governance overlay on a workspace, for two or more parties who must collaborate without trusting each other and compute a joint result without exposing raw data.
It is never "how sensitive is the data?". It is "how many trust domains are in the room?" One → workspace. Two or more that must collaborate without trusting each other → clean room.
Every store on a cell maps back to one of these boundaries. Because they span cells, a workspace or clean room is a portable unit: it can be cloned, archived, moved between organizations, and failed over as a whole, independent of which cell its data currently sits on.
Version skew is normal
Cells are independent instances, not replicas of a single master, so skew is expected on two axes and capabilities are designed to tolerate both:
- New code against an older database: a cell running a newer build reads a schema written by an older one.
- One cell against a peer several releases ahead: cells in the same estate need not be on the same version to coordinate.
This is a design constraint, not a failure mode. A change that assumes every cell is on the same version is a change that breaks a real estate.
Permanent and ephemeral cells
Cells can be long-lived, or launched ephemerally, roughly a hundred at a time for a single job, each its own complete instance. Because the smallest useful deployment is a full platform, per-cell startup cost multiplies in exactly the case that matters most, so it is treated as a first-class scaling concern rather than an afterthought.
Coordinating many cells
A single cell is complete on its own. When cells are grouped, they coordinate as peers rather than through a central master:
- Fabric. Each cell publishes its endpoints into a fabric table that is reconciled at boot and on every certificate rotation; peers discover each other through it.
- Distributed leases. Cross-cell singletons are elected through time-to-live leadership leases, so leadership survives a cell going away.
- Per-table replication. Replication policy is declared per table, in one of three modes: local to a cell, mirrored within a service group, or symmetric across every peer. What replicates and how is a property of the data, not a global switch.
The result is that the same code runs unchanged as a single sovereign box, as a service group, or as a federated multi-cell estate. How those shapes are chosen is the subject of Deployment topology.
Related topics
- Each cell carries the full Data Platform, whose database substrate is the per-cell store described above.
- The Edge Agent runs alongside (or without) a cell; see Core and edge.
- Identity for entities, cells, and nodes is a Security concern shared by every capability on the cell.