These are chat archives for atomix/atomix
AtpmixReplicawhich you can use as an example. This is the way I'd recommend more or less embedding the server. Otherwise, as @jhalterman said the protocol for interacting with state machines is really deeply embedded in Copycat and is already built in to clients. The way it's done in
AtomixReplicais by using the
LocalTransportwhich just uses queues rather than networks. Configure the servers with a
LocalTransport, then configure a client with the same
LocalTransportinstance. This is why that abstraction exists.
Transportservers use to communicate with each other, which presumably still needs to be a network, and the
Transportclients use to communicate with servers, which can be
LocalTransportif no client needs to connect remotely. This is how I would build a REST API on top of Copycat. Then if you don't need to use sessions then the overhead of sessions is limited to the number of nodes in the cluster. If you do need to use sessions them create a separate
clientTransportto the leader via the
LocalTransporton a server since servers may still proxy sequential reads to another node if the local node is too far behind the leader or is partitioned from the leader.
AtomixClienttechnically only needs one server to connect to. But the availability of your cluster is dependent on the number of nodes. Two or fewer nodes doesn’t allow any nodes to fail, meaning if a node fails the system will stop working. It will work perfectly fine with one or two nodes, but only if those one or two nodes are available at all times.