State machine replication, and why you should care

If you're interested in this topic, I highly suggest some of the talks and papers about the LMAX Disruptor [0] and Martin Thompson's latest project Aeron [1]. It targets the JVM, but the lessons are generally applicable since I don't think Concord/Aria are open source.

[0] https://lmax-exchange.github.io/disruptor/ [1] https://github.com/real-logic/aeron

This seems like a more restrictive version where the "Actors" must also be entirely deterministic and single threaded without really blocking in the middle of processing something.

I can see how you would think they are similar!

Actors usually refers to a scheme with multiple coroutines which communicate via message passing. The emphasis is on the fact that there is no shared state: all communication happens via message passing. It's usually something which comes up in programming language design.

State Machine Replication usually refers to a scheme where all operations are serialized to a log and have a completely deterministic result, allowing you to reach the same state on any other machine simply by replaying the log. The emphasis is on existence of that persistence log, and on the deterministic result of applying it. It's usually something which comes up in distributed systems. It's also a common pattern in databases though it's usually just called "replication".

Erlang is the classic actor model example. Most erlang deployments do not keep persistent logs of messages. There are "inbox"es but those are transient and message disappear as soon as they are processed, actors are also not required to have deterministic responses to incoming messages. So, most erlang programs do not resemble state machine replication!

The classic example of SMR is something like Postgres streaming replication. One machine saves all changes to a log before it commits any transactions, and another machine is continuously processing that log. This gives you two instances of the database, making it easy to switch over to the second machine if the first one ever fails. This kind of looks like actors, if you squint, but usually when we talk about actors we don't think of each of the processes running on each of our machines as actors.

This is somewhat interesting but note they start by saying they use the word "state machine" not in fact to refer to a state machine, but rather something more like a closure or class instance (they weren't really clear).

As a Vert.x fanatic, LMAX Disruptor is one of the few technologies for JVM that makes my jaw drop. So cool.