A cluster that coordinates itself
Nodus is a clustering and messaging core you embed in your process. Every member runs the same layers over a shared transport — so membership, leadership and messaging emerge from the nodes themselves, with no external coordinator to operate.
Peers, not a coordinator
Each member holds a persistent connection to every peer and runs the same four layers. There is no privileged node the others depend on — the leader is simply the member they all elect.
Four layers, one dependency
The hard parts of running more than one instance — solved once and embedded, so you write application code, not distributed-systems plumbing.
Transport
A long-lived connection to each peer carries every plane — membership, messaging, events and health — with a priority lane so control traffic is never starved by bulk payloads.
Membership
Nodes admit each other from a peer set and keep a live roster. Joins and leaves surface as events; a gossip digest rides existing traffic to reconcile views without a registry service.
Coordination
Every member runs the same election over the same reachable peers and independently picks the same leader — carried on an epoch counter so a stale leader is always distinguishable from the current one.
Messaging
Send a typed payload to one peer or all of them, await a typed reply matched by correlation id, or publish on a cluster-wide event bus — all over the same transport.
No external coordinator, by design
- No ZooKeeper, etcd or ConsulCoordination lives inside your process as a library. There is no external quorum service to stand up, secure, upgrade or keep alive — one less distributed system to operate.
- Every node runs the same logicThere is no special coordinator process. Each member computes membership and leadership from the same inputs, so the cluster keeps working as long as the members can reach each other.
- Forms and heals itselfNodes discover peers, agree on a leader, and re-converge after joins, leaves and failures on their own — the cluster is an emergent property of the members, not a service they depend on.
Leadership carried on an epoch
Every election result is stamped with a monotonically increasing epoch. When a node joins or the leader fails, the survivors re-elect and the epoch advances — so a message or claim from a stale leader can always be told from the current one, and failover never leaves two nodes each believing they lead.
- Deterministic strategy — highest-id or oldest-node — over the same reachable peers
- A tiebreaker resolves equal-epoch collisions to exactly one leader
- The epoch increments on every change, so leadership is always orderable
See it run in your own service
Embed Nodus, join a cluster, and follow the leader in a few lines — then read how membership and failure detection keep it honest.