Two coordinated nodes. Workload distribution. Replication. Failover. The shift from "satellite" to "infrastructure".
Demonstrate that orbital data centers become more valuable when they operate as a coordinated infrastructure layer instead of isolated satellites.
A single orbital node is impressive engineering. A coordinated cluster is a different category workloads can move across nodes by contact opportunity, by thermal margin, by customer policy. Node-3 is the first STELLAR mission that operates as more than one spacecraft. It is the moment "orbital data center" stops being a metaphor.
A workload submitted to Node-3 isn’t pinned to a specific spacecraft. The scheduler chooses the node with the best joint state power, thermal, contact, and locality of input data and replicates results across nodes for delivery resilience. If a node enters safe-mode, in-flight jobs and stored products fail over to a peer.
Node-3 keeps the Node-2 customer contract surface same API, same SLAs but the implementation underneath is now distributed. Customers don’t see the complexity; they see better delivery times and a service that survives a single-node degradation. Operations sees two spacecraft, one cluster health view, one reconciliation log.
The profile is the mission’s physical truth every architectural choice descends from these numbers.
The mission is the sum of these subsystems and the way they constrain each other.
| System | Specification | Design note |
|---|---|---|
| Cluster scheduler | Joint-state scheduler power, thermal, contact, locality | Picks the node best suited to a workload by joint orbital state and customer policy. Failover-aware: in-flight jobs migrate when a peer node degrades. |
| Inter-node link | RF inter-satellite link (Ka-band class) | Carries replication traffic, cluster heartbeats, and cross-node command authorization. Optical relay is staged for Node-5; Node-3 uses RF for risk-reduction. |
| Replication storage | Cross-node mirrored pools, customer-policy-driven | Customer policy chooses replication: local-only, cluster-mirrored, or quorum-of-N. Hash-chain integrity preserved across nodes. |
| Cluster health model | Single ground-cloud view of two-node state | Operations and customer dashboards show cluster state power, thermal, contact, queue depth, replication lag, SLA budget as a single coordinated view. |
| Cross-node receipts | Quorum-signed delivery evidence | Delivery is acknowledged when N-of-M nodes have signed the result. Lets the customer verify that no single spacecraft owns the truth. |
Each mission is justified by a specific new capability not just a larger payload.
Workload distribution across more than one orbital node
Replication and failover for selected datasets
Resource scheduling across power, contact, thermal, and storage constraints
Cluster health model visible to ground-cloud operations
Cross-node delivery reconciliation with quorum receipts
Customer-policy controls for replication, residency, and durability
The plan is broken into reviewable phases. Each phase ends in a deliverable a stakeholder can read.
Scheduler protocol, replication policy model, ISL contract, and ground-cloud cluster view defined.
First cluster member launched. Operates standalone (Node-2-class) until Node-3b joins; pre-flight verifies ISL acquisition.
Second member launched; ISL acquisition; cluster scheduler activated; first cross-node workload migration.
Steady-state cluster operation. Replication, failover, quorum delivery exercised under live customer load.
A serious mission tracks risks honestly. Closed, mitigated, in design, and open items are listed without softening.
| Risk | State | Description |
|---|---|---|
| ISL link availability and latency | In design | RF inter-satellite link availability windows drive replication lag. Node-3 architecture must tolerate multi-orbit ISL gaps without breaking customer SLAs. |
| Split-brain on partial connectivity | In design | Cluster scheduler must avoid double-execution under transient ISL loss. Resolved through quorum protocols and ground-mediated tiebreak. |
| Operations cognitive load | Mitigated | Cluster health view collapses two-node state into one operator workflow. Validated against synthetic split-brain scenarios in GroundLab. |
| Coupled launch dependency | Open | A coordinated cluster requires two functioning nodes. Risk is mitigated by staggered launches: Node-3a flies as standalone Node-2.5 if Node-3b slips. |
The right way to read a mission page: claim → evidence → state. If a row is in the wrong state, the page is what is broken not the program.
| Claim | Evidence | State |
|---|---|---|
| Workload migrates across nodes without customer-visible SLA breach. | Cluster scheduler log + customer SLA reconciliation | Planned |
| Stored products survive one-node safe-mode without loss. | Quorum receipt chain + replication lag telemetry | Planned |
| ISL link maintains contracted replication budget. | On-orbit ISL availability vs. mission baseline | Planned |
| Operations workflow stays single-pane under two-node state. | Operator usability + incident-response playbook execution | Draft |
Each mission is a step on a single staircase. These bridges spell out what comes from the prior step and what becomes possible after.
Node-3 inherits the Node-2 customer contract and SLA model. Underneath, single-node implementation is replaced by a cluster scheduler with replication and failover invisible to customers, decisive for the infrastructure thesis.
← Open Node-2Once a working cluster is operational, Node-4 introduces tenant isolation, regulatory framing, and the protected-region model that government and enterprise resilience customers require.
Open Node-4 →