Loading...
System Design and AI Engineering, by Roni Das. 974 interactive lessons.
Start LearningAdvanced · Distributed Systems Core
A behavioral design pattern where an object delegates its behavior to a separate object for its current state and swaps that object when the state changes, a clean way to build a finite state machine.
In short
The State pattern is a design pattern that lets an object change its behavior when its internal state changes, by handing each request to an object for its current state. It is the object-oriented way to build a finite state machine.
In short
The State pattern is a design pattern that lets an object change its behavior when its internal state changes, by handing each request to an object for its current state. It is the object-oriented way to build a finite state machine.
This page is the free part.
₹499 in India$49 everywhere elseonce, for the whole course
The System Design course covers State Pattern across a run of lessons, not one page. These 4 alone are about 88 minutes of step-by-step reading, 2 of them with code you run in the browser, all with a quiz.
What a finite state machine is, DFA vs NFA, and how TCP and Kubernetes pods use one. Includes a type-safe state machine in code.
Model system behavior as a finite set of states and transitions, the foundation of distributed protocols.
Let objects subscribe to events and react when something changes, the foundation of event-driven systems.
Encapsulate requests as objects, enabling undo, queuing, logging, and distributed task execution.
all part of
System Design Masterclass
770 lessons · about 283 hours · 18 free to read
₹499in India, by UPI
$49everywhere else, by PayPal
Ive started this course by accident - LLM advised me this site. When I passed few free lessons, I had no doubt - this course should be bought. And I did it with special pleasent price and it was best decision of the month. Content is great, interesting to read and with a lot of practial cases (what makes it different from other souces and books) I hope to teach all the lessons, that will be my supergoal. Glad that I found this resource and speacial Thank You to Roni Das - Great Job!
You own this course
Continue with Finite State Machinepay once,
yours for life
Many objects behave differently depending on where they are in their life. An order that is not yet paid can be paid or cancelled. An order that has shipped can only be delivered. The same method call, cancel(), should work in one case and be refused in the other.
The usual first version of this code is a status field plus a switch statement in every method. Each method asks "what state am I in?" and branches. With five states and four events, that is twenty cases spread across four methods. Adding a state means editing every one of them.
The State pattern is one of the 23 patterns in the 1994 Gang of Four book. Its intent is to let an object alter its behavior when its internal state changes, so that the object appears to change its class. It is a behavioral pattern, one of the group about how objects share work.
It has three roles. The context is the object the rest of the program talks to, here the order. The state interface lists every event the context can receive. Each concrete state is one class that implements that interface for one state. The context holds a reference to its current state object and passes every event to it. When a transition happens, the context swaps that reference for a new state object.
A finite state machine is a model with a fixed, countable set of states and a set of inputs. A rule maps each state and input to the next state. The Finite State Machine lesson defines it formally and shows it in TCP, in the Kubernetes pod lifecycle and in Stripe payment intents.
To be clear about the lesson: it does not use the State pattern. It builds an order machine with a transition table. The table says created can go to paid or cancelled, and paid can go to shipped or cancelled. Shipped can only go to delivered. Delivered and cancelled are terminal, meaning nothing leaves them. One lookup in the table gives the next state, and a missing entry is an invalid move.
The State pattern is a second way to build the same machine. The same states and the same arrows are there. They are just held in a different shape. In the table, the transitions are data in one place. In the State pattern, each state is an object, and each object knows which events it accepts and which state comes next.
Drawn from the lesson Finite State Machine.
Here is the lesson's machine rewritten with the State pattern. The base class refuses every event. Each concrete state overrides only the events it accepts. The order itself has no branch on its own state. The code was run with Node.js before it was added here.
order-state.js
// The lesson's order lifecycle, written as state objects instead of a table.
// Each state knows which events it accepts and which state comes next.
class OrderState {
pay(order) { this.refuse("pay"); }
ship(order) { this.refuse("ship"); }
deliver(order) { this.refuse("deliver"); }
cancel(order) { this.refuse("cancel"); }
refuse(event) { throw new Error(`Invalid: ${this.name} + ${event}`); }
}
class Created extends OrderState {
name = "created";
pay(order) { order.moveTo(new Paid(), "pay"); }
cancel(order) { order.moveTo(new Cancelled(), "cancel"); }
}
class Paid extends OrderState {
name = "paid";
ship(order) { order.moveTo(new Shipped(), "ship"); }
cancel(order) { order.moveTo(new Cancelled(), "cancel"); }
}
class Shipped extends OrderState {
name = "shipped";
deliver(order) { order.moveTo(new Delivered(), "deliver"); }
}
class Delivered extends OrderState { name = "delivered"; } // terminal
class Cancelled extends OrderState { name = "cancelled"; } // terminal
// The context. It has no if-else on its own state: it hands each event to the state object.
class Order {
constructor() { this.state = new Created(); }
moveTo(next, event) {
console.log(`${this.state.name} --[${event}]--> ${next.name}`);
this.state = next;
}
pay() { this.state.pay(this); }
ship() { this.state.ship(this); }
deliver() { this.state.deliver(this); }
cancel() { this.state.cancel(this); }
}
const order = new Order();
order.pay(); order.ship(); order.deliver();
console.log(`Final state: ${order.state.name}`);
const order2 = new Order();
order2.pay();
try { order2.deliver(); } catch (e) { console.log(e.message); }
order2.cancel();
console.log(`Final state: ${order2.state.name}`);Output, captured 2026-10-04 (node order-state.js)
created --[pay]--> paid
paid --[ship]--> shipped
shipped --[deliver]--> delivered
Final state: delivered
created --[pay]--> paid
Invalid: paid + deliver
paid --[cancel]--> cancelled
Final state: cancelledThe output follows the same two paths as the lesson's table version: the happy path to delivered, and a cancellation. The invalid move, deliver on a paid order, is refused with the same kind of error the lesson's table throws. Here it comes from the Paid class, which simply does not override deliver().
Both shapes build the same machine, so the choice is about what changes most often.
Whichever you pick, keep the rules of the lesson's tradeoffs slide in mind. A state machine fits when the states are a manageable, fixed set. For nested flows, such as a login inside a checkout, use hierarchical state machines, also called statecharts. For two or three states with obvious moves, a plain enum is fine.
The two patterns have the same structure. A context holds a reference to an interface and passes work to it. The difference is who swaps the object.
The Strategy Pattern lesson gives the test in one line. If someone outside the object chooses the behavior, it is Strategy. If the object changes its own behavior based on what happened to it, it is State. Its example is a circuit breaker going from CLOSED to OPEN.
A circuit breaker is a guard in front of a remote call. CLOSED lets calls through. After too many failures it moves to OPEN and fails fast. After a wait it moves to HALF_OPEN and lets a test call through. Nobody outside picks these states. The breaker moves itself, based on what its calls return. That is State. See circuit breaker states for the full machine, or the Circuit Breaker Pattern lesson.
A second clue: strategies usually do not know about each other. State objects often do, because each one creates the next. In the code above, Created creates Paid and Paid creates Shipped.
For the rest of the catalogue, see design patterns. The best next step after this page is the Finite State Machine lesson. It covers DFA vs NFA, the TCP machine, the Kubernetes pod lifecycle and a type-safe version of the order machine.
TCP connections
The lesson describes TCP as a finite state machine with 11 states. Its comparison slide lists a TCP connection, with LISTEN, ESTABLISHED and CLOSED, as a State example.
Circuit breakers
CLOSED, OPEN and HALF_OPEN, switched by the breaker itself as calls fail and recover. The Strategy lesson uses it as the example of State, not Strategy.
Stripe Payment Intents
The lesson shows a payment intent moving through states such as requires_payment_method, processing, succeeded and canceled, each change caused by an API call or webhook.
Kubernetes Pods
Each Pod has a phase: Pending, Running, Succeeded, Failed or Unknown. The lesson uses it as a state machine that runs on every node.
It is a behavioral design pattern that lets an object change its behavior when its internal state changes. The object, called the context, holds a reference to a state object and passes every request to it. Each state is its own class. A transition replaces the state object, so the same method call now behaves differently.
An order is a simple one: created, then paid, then shipped, then delivered, with a cancel allowed only before shipping. TCP is another, with 11 states for one connection. Kubernetes runs one for every Pod, with phases such as Pending, Running and Failed. A circuit breaker moving between CLOSED, OPEN and HALF_OPEN is a third.
The structure is the same as in any object-oriented language. You declare an abstract State class with one virtual function per event. Each concrete state is a subclass that overrides the events it accepts. The context holds a pointer to its current state, often a std::unique_ptr, and replaces it on each transition.
They share a structure but differ in who swaps the object. In Strategy, the client or the config picks the algorithm from outside. In State, the object changes its own state as events happen, and states often know which state comes next.
Checked against these on .
Design Patterns
Named, reusable solutions to problems that keep coming up in object-oriented code, such as creating objects, wrapping interfaces or reacting to events. The classic catalogue of 23 was published by the Gang of Four in 1994.
Strategy Pattern
A behavioral design pattern that puts each version of an algorithm in its own class behind one interface, so code can swap the algorithm at runtime instead of growing an if-else chain.
Circuit Breaker States
A circuit breaker cycles through three states: Closed (requests flow normally), Open (requests are blocked after failures), Half-Open (a few test requests check if the service recovered).
State Machine Replication
Running the same deterministic state machine on multiple nodes, applying the same commands in the same order. If they start in the same state and see the same inputs, they stay in sync.
CAP Theorem
When a network failure splits a distributed data store, each node must either refuse requests to stay consistent or keep answering with possibly stale data. It cannot guarantee both during the partition.
Consensus
The process of getting multiple nodes in a distributed system to agree on a single value. The foundation of distributed databases and coordination services.
This page explains the idea. The "Finite State Machine" lesson builds it up step by step, with diagrams. It is part of the System Design Masterclass course, which has 770 lessons. 18 of them are free to read. You pay once and keep it for life, with no subscription.
Open the Finite State Machine lessoncourse 1
From absolute beginner to principal engineer, drawn step by step.