Status: Canic 0.101 is currently a design, not a shipped implementation. The
foundational 0.100 multi-subnet work remains in progress.
https://github.com/dragginzgame/canic/
Canic 0.101 introduces a deployment model capable of representing almost any practical
multi-subnet application topology while retaining a deliberately simple runtime
hierarchy.
The central rule is:
Fleet Subnet Root
└── Component
└── Component Children
Every physical subnet occupied by a Fleet has one Fleet Subnet Root for that Fleet.
Different Fleets can use the same physical subnet while retaining completely separate
roots, registries, limits and authority.
The Fleet Coordinator sits outside this hierarchy. It owns Fleet-wide topology and
publication, while each Fleet Subnet Root manages the Components placed on its subnet.
Components Instead of Runtime Trees
A Component Spec describes one reusable Component role and its permitted direct
children.
Examples include:
- a user hub with dynamically created user shards;
- a project hub with project-instance children;
- an authoritative database;
- a read-only database replica; or
- a stateless service member.
Components can create large numbers of local children without involving the
Coordinator. That gives Canic two useful levels of scaling:
- Fleet-wide scaling by placing additional Components across Fleet Subnet Roots.
- Root-local scaling through Component Children such as shards and instances.
There is no arbitrary recursive management hierarchy. Keeping the runtime topology
flat makes lifecycle authority, limits, recovery and ownership much easier to reason
about.
Component Groups Describe Deployment Composition
Canic 0.101 adds Component Groups for workloads that should be deployed together.
Groups can include other groups in configuration, but Canic completely flattens them
before creating anything. There is no Group Canister, Group controller or additional
runtime layer.
For example:
project_cell
├── project_hub
└── databases
├── database_a replica
├── database_b replica
└── database_c replica
This becomes four direct Components under the selected Fleet Subnet Root.
Every concrete placement receives a stable identity. The same group can be deployed
repeatedly, including several times on one subnet when intentional co-location is
useful.
Pack Together or Spread Apart
Placement policy can express both density and minimum spread.
This allows applications to choose between:
- one placement per subnet for failure isolation;
- several placements on one subnet for lower latency;
- an authoritative service on a high-replication subnet;
- read replicas distributed across application subnets;
- active service pools spread across several subnets; or
- dense, specialised subnets dedicated to one workload.
Canic does not assume that every subnet contains an identical shard.
A Toko-style deployment could therefore look like:
User subnet
Fleet Subnet Root
└── user platform
Authoritative database subnet
Fleet Subnet Root
├── database_a authority
├── database_b authority
└── database_c authority
Project subnet 1
Fleet Subnet Root
├── project hub
├── database_a replica
├── database_b replica
└── database_c replica
Project subnet 2
Fleet Subnet Root
└── another project placement
…
Project subnet N
Fleet Subnet Root
└── another project placement
The user subnet could devote most of its capacity to onboarding and identity. Project
subnets could be filled with independently scaled project workloads. Authoritative
databases could live on a higher-replication subnet without making the Coordinator
part of the database topology.
Fleet Services and Discovery
Canic 0.101 separates Component identity from Fleet service identity.
Two initial service modes are proposed:
- Authority/Replica: one configured Authority and zero or more same-Spec Replicas.
- Active Pool: one or more same-Spec Pool Members.
Canic publishes the configured endpoints and their intended purpose. It does not
pretend to know whether application data is synchronized, whether a replica is ready,
or which pool member is healthy. Those remain application responsibilities.
This keeps Canic responsible for deployment truth without turning it into an
application router, load balancer or database-consistency protocol.
Scaling With the Number of Subnets
The architecture scales horizontally because control is partitioned by physical
subnet:
- the Coordinator manages Fleet-wide root and service topology;
- each Fleet Subnet Root manages its own Component identities and lifecycle;
- Component Registries and Directories remain local to their root; and
- high-cardinality children remain local to their owning Component.
The Coordinator does not manage every project instance or shard individually.
A fresh 0.101 Fleet can be planned across many subnets, and same-release group scale-
out can add placements on already-installed, already-admitted roots. Dynamic creation
of new roots and operational worker partitioning are separate follow-on concerns.
Authority Remains Simple
Even as the deployment grows, every responsibility still has one clear owner:
- the Coordinator owns Fleet-wide topology and publication;
- each Fleet Subnet Root owns local lifecycle operations;
- each Component owns its application policy;
- Component Children cannot become lifecycle managers; and
- application data and routing remain application concerns.
Co-location does not merge authority. Two Fleets may use the same physical subnet
while retaining independent roots, registries, stores, limits and controllers.
What Canic Deliberately Does Not Do
Canic 0.101 is not intended to become an arbitrary graph of recursive canister
managers.
It does not automatically provide:
- application routing;
- database replication;
- replica readiness;
- leader election or promotion;
- load-balancer health;
- arbitrary Component nesting;
- automatic scale-in; or
- unrestricted live admission expansion.
Those responsibilities require their own explicit protocols rather than being implied
by placement.
The Result
Canic 0.101 provides a small set of composable primitives capable of expressing a very
wide range of real deployments:
- specialised subnets;
- replicated services;
- active pools;
- co-located workload cells;
- anti-affinity across subnets;
- independently scaled tiers; and
- high-cardinality local shards.
The topology can become large and heterogeneous without making its authority model
equally complicated.
