A Cluster joins independent JVM-based ActorSystems into a peer-to-peer whole. Nodes can be added or removed as demand changes, while decentralized coordination avoids a single point of failure and supports fault tolerance. section 8.0
Cluster builds on akka-remote to make actor location transparent: business logic can communicate with an actor without needing to know whether it runs locally or on another node. Its core goals are fault-tolerant membership, distributing actor subtrees across nodes, and automated failover. section 8.2
Use the four-node view to distinguish one clustered ActorSystem deployment from a single JVM: each node participates in the same peer-to-peer cluster. section 8.2
A practical cluster setup separates formation and operations from application behavior:
- Configure the actor provider, remote settings, and seed nodes, then start an ActorSystem to form a basic cluster. section 8.6
- Track member lifecycle transitions: Joining, WeaklyUp, Up, Leaving, Down, Exiting, and Removed. section 8.6
- Use Akka Management and Management Cluster HTTP to inspect or change node state over HTTP; use Cluster Bootstrap and discovery instead of static contact configuration when appropriate. section 8.1
- Keep business logic independent of cluster formation so application behavior can be tested without cluster concerns. section 8.6
Resilient word counting
A word-counting workload can run actors on different nodes. After some nodes stop, new nodes can join and counting continues without lost work, illustrating how clustering combines scale-out processing with resilience. section 8.2 section 8.6
Cluster capabilities extend beyond membership. Cluster Singleton keeps one relocatable actor instance; Cluster Sharding distributes actors by partition key; Distributed Data supplies eventually consistent key-value objects; and Reliable Delivery adds at-least-once guarantees. section 8.1
