Using Akka.Cluster and State Machines to Build Reactive Systems
Petabridge recently launched its first cloud service, Sdkbin, and it’s been a great opportunity for our team to use the Akka.NET tools, patterns, and practices that we’ve been recommending to our customers for years.
In this blog post I’m going to walk through one of the most universal real-world Akka.NET actor patterns: the state machine.
Finite State Machines: a Primer
One of the major drawbacks of web programming is that due to its stateless and non-local affinity, many programming patterns that were commonplace in embedded, desktop, and client programming have lost their importance in everyday programming. These “lost patterns” tend to be stateful ones - and none more so than the “finite state machine” or “FSM” for shorthand.
The idea behind a finite state machine is simple but powerful:
- For a given type of entity modeled in your software system it can exist in one of many possible states - but it can only occupy a single state at a time;
- An entity usually has some “state data” objects that provide contextual information for the current unit of work in process - i.e. an
Orderentity might be in an
Openstate and have an
OrderDataobject that contains a unique orderId, customerId, and so on;
- As the state machine processes events both its state and its state data can change - in particular, the state machine can transition from one state to another in response to 1 or more events being processed; and
- States can be re-entrant - an entity can return to its original state in the event of a timeout, error, or based on the type of event it processed.
When Do You Need a State Machine?