State Machine

Think about an elevator. It can only be in a few states at any given moment, moving up, moving down, doors open, doors closed, idle. It can't be moving up and have its doors open at the same time. If it could, people would die.

The elevator doesn't "think" about what to do next. It follows a rigid set of rules: if you're idle and someone presses a button on floor 5, transition to "moving up." If you've arrived at floor 5, transition to "doors opening." There's no ambiguity. No creativity. Just states and transitions.

This is exactly how distributed systems work, or at least, how the reliable ones work. Every Raft consensus node, every TCP connection, every payment processor follows a state machine. The reason is brutally pragmatic: when you have dozens of servers trying to agree on something, you cannot afford ambiguity. If server A thinks the state is "committed" and server B thinks it's "pending," you have a bug that will corrupt data.

State machines eliminate that class of bug entirely. They force you to enumerate every possible state, every possible transition, and every impossible transition. If a transition isn't explicitly defined, it doesn't happen. Period.

The irony is that most developers have been using state machines their entire career without knowing it. HTTP request lifecycle? State machine. Promise states (pending, fulfilled, rejected)? State machine. Git branch workflow? State machine. Once you see the pattern, you can't unsee it.

A state machine is a mathematical model of computation. It consists of exactly three things:

States, a finite set of conditions the system can be in. An order might be: created, paid, shipped, delivered, refunded. That's five states. Not four. Not six. Five. Every possible condition is accounted for.

Transitions, rules that define how you move from one state to another. An order moves from "created" to "paid" when payment succeeds. It moves from "created" to "cancelled" when the user cancels. It cannot move from "delivered" to "created", that transition doesn't exist, so it can't happen.

Events, the triggers that cause transitions. A "payment_received" event triggers the created-to-paid transition. A "shipment_confirmed" event triggers the paid-to-shipped transition.

Here's what makes state machines powerful: they're complete. You don't handle the happy path and hope the sad path works out. You explicitly define what happens for every combination of state and event. What happens if a "payment_received" event arrives when the order is already in "shipped" state? You define that. Maybe it's a no-op. Maybe it raises an alert. But it's defined.

This completeness is why distributed systems rely so heavily on state machines. In a distributed environment, messages arrive out of order, get duplicated, or get lost entirely. A state machine handles all of that because every scenario has a defined outcome.