Loading...
System Design and AI Engineering, by Roni Das. 974 interactive lessons.
Start LearningIntermediate · Microservices Architecture
A behavioral design pattern that turns a request into an object holding everything needed to run it, so requests can be queued, logged, retried or undone.
In short
The command pattern is a behavioral design pattern that turns a request into an object holding everything needed to run it. Because the request is now an object, you can queue it, log it, retry it or undo it.
In short
The command pattern is a behavioral design pattern that turns a request into an object holding everything needed to run it. Because the request is now an object, you can queue it, log it, retry it or undo it.
This page is the free part.
₹499 in India$49 everywhere elseonce, for the whole course
The System Design course covers Command Pattern across a run of lessons, not one page. These 4 alone are about 91 minutes of step-by-step reading, every one with a quiz.
Encapsulate requests as objects, enabling undo, queuing, logging, and distributed task execution.
Retry failed operations intelligently, exponential backoff, jitter, and retry budgets.
Schedule messages for future delivery, process them later, not now.
Let objects subscribe to events and react when something changes, the foundation of event-driven systems.
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 Command Patternpay once,
yours for life
The lesson starts in a restaurant. When you order, the waiter does not walk into the kitchen and cook. The waiter writes your order on a slip, hands it to the kitchen and goes back to other tables. The slip holds everything needed: the dish, the changes you asked for, the table number. The kitchen can cook it now, queue it behind other orders, or reject it if an ingredient has run out.
That slip is a command object. The Command pattern is one of the 23 patterns in the 1994 Gang of Four book. Its intent is to encapsulate a request as an object. That lets you pass requests around as values, queue them or log them, and support operations that can be undone.
Why does that matter? A normal method call runs once and is gone. You cannot put it in a queue, save it to disk or reverse it later. A command object is a thing you can hold. You can store it, send it to another machine, run it later, run it again, or call its undo method.
The lesson maps each role to the restaurant.
Drawn from the lesson Command Pattern.
The key line from the lesson: the invoker never touches the receiver directly. The command is the only object that knows both how to do the work and how to reverse it.
In the lesson's email example, the client builds a SendEmailCmd with the recipient, subject and body, and pushes it onto a queue. Later the queue calls execute(). The command calls send() on the email service and keeps the message ID it gets back, msg_42. If the user clicks "unsend", the queue calls undo() on the same command, and the command calls recall(msg_42).
This is the lesson's email flow as runnable code. The invoker is a queue with a history list, so it can undo the last command. The code was run with Node.js before it was added here.
send-email-command.js
// Receiver: the object that does the real work.
class EmailService {
constructor() { this.sent = new Map(); this.nextId = 42; }
send(to, subject) {
const id = `msg_${this.nextId++}`;
this.sent.set(id, { to, subject });
console.log(`sent ${id} to ${to}: ${subject}`);
return id;
}
recall(id) { this.sent.delete(id); console.log(`recalled ${id}`); }
}
// Command: the request as an object. It holds the arguments and knows how to undo itself.
class SendEmailCmd {
constructor(receiver, to, subject) { Object.assign(this, { receiver, to, subject }); }
execute() { this.messageId = this.receiver.send(this.to, this.subject); }
undo() { this.receiver.recall(this.messageId); }
}
// Invoker: a queue. It runs commands later and keeps a history for undo.
// It never calls the email service itself.
class Invoker {
constructor() { this.queue = []; this.history = []; }
submit(cmd) { this.queue.push(cmd); }
runAll() {
while (this.queue.length) { const cmd = this.queue.shift(); cmd.execute(); this.history.push(cmd); }
}
undoLast() { this.history.pop()?.undo(); }
}
// Client: builds the commands and wires each one to its receiver.
const email = new EmailService();
const invoker = new Invoker();
invoker.submit(new SendEmailCmd(email, "asha@example.com", "Order confirmed"));
invoker.submit(new SendEmailCmd(email, "ravi@example.com", "Order shipped"));
console.log(`queued: ${invoker.queue.length}, sent so far: ${email.sent.size}`);
invoker.runAll();
invoker.undoLast();
console.log(`still sent: ${[...email.sent.keys()].join(", ")}`);Output, captured 2026-10-04 (node send-email-command.js)
queued: 2, sent so far: 0
sent msg_42 to asha@example.com: Order confirmed
sent msg_43 to ravi@example.com: Order shipped
recalled msg_43
still sent: msg_42Read the first output line. Two commands are waiting and nothing has been sent. That is deferred execution: the request exists before it runs. Then both run, and undo reverses only the last one, because the history is a stack. Each command kept its own message ID, which is the state it needs to reverse itself.
Because a command is an object that lives for a while, it moves through states. The lesson draws six. Created, when the client builds it. Queued, when it is handed to the invoker. Executing, when the invoker calls execute(). Then Done on success, or Failed on an error. A failed command can go back to Queued for a retry, up to a set limit. A done command can move to Undone if it supports undo.
This is how task queues behave. In Amazon SQS, a worker takes a message and the message is hidden from other workers for a while, the visibility timeout. If the worker finishes, it deletes the message. If the worker dies first, the message becomes visible again and another worker picks it up. After too many failed tries, the message can be moved to a dead-letter queue, a side queue for messages that keep failing.
Not every command can be undone. The lesson warns that a sent email or a deleted file may only be reversible in a weaker sense, such as a recall or a soft delete. Design undo per command, and say clearly which ones have none.
The lesson calls every task queue the Command pattern at scale. A job in a message queue such as SQS, RabbitMQ or Bull is a serialized command. It names the work to do and carries the arguments. Workers take jobs off the queue and run them.
Redis persistence is another case. With the append-only file turned on, Redis appends every write command it receives, such as SET, to a log on disk. After a restart, it replays the log to rebuild the data. The commands, written down in order, are the durable record.
In CQRS, the C stands for Command. Writes are modelled as command objects, sent to a handler, checked and run. Reads use a separate path, so the two sides can scale on their own.
Event sourcing is a close cousin, and the lesson treats it as one. To be precise, event sourcing stores events, which are facts that already happened, such as OrderPlaced. A command is a request that may still be refused, such as PlaceOrder. A command handler checks the command and, if it is valid, records one or more events.
All three patterns put behavior inside an object. The lesson separates them by when the object runs.
The lesson's rule for interviews is about lifecycle. Command defers execution and keeps enough state to undo. Strategy runs now and keeps nothing. If you need a queue, you need Command.
When not to use it: plain CRUD calls with no queue and no undo. Wrapping every database call in a command object adds ceremony with no benefit, and not every POST endpoint needs a command bus. For the full catalogue, see design patterns. The best next step is the Command Pattern lesson, which steps through the execute and undo flow and ends with a short quiz.
Amazon SQS
A message is a serialized command. The visibility timeout hides it while a worker runs it, and it reappears for another worker if the first one dies.
Redis append-only file
Every write command is appended to a log and replayed at startup to rebuild the dataset.
Undo in editors
Each edit is a command with an undo method, kept on a history stack. Ctrl+Z pops the last one and reverses it.
Celery, RabbitMQ and Bull
The lesson lists these task queues as the Command pattern at scale: a job names the function to call and carries its arguments.
It is a behavioral design pattern that wraps a request in an object holding everything needed to run it: the operation, its arguments and the receiver that will do the work. An invoker can then run the object later, queue it, log it, retry it or undo it, without knowing what it does.
A strategy is a way of doing a task, swapped into a context and called right away. A command is one specific request, stored as an object so it can run later. Commands support queuing, history and undo. Strategies keep no history. If you need a queue or undo, use Command. If you need to swap algorithms, use Strategy.
The Gang of Four group their 23 patterns as creational, structural and behavioral. Creational patterns create objects, structural patterns combine them, and behavioral patterns divide work between them. Command is behavioral, like Strategy and Observer.
Yes, in the lesson's mapping. The job is the command, the queue acts as the invoker that decides when to run it, and the worker plays the receiver that does the work. Retries and dead-letter queues are the command lifecycle handled by the queue.
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.
Message Queue
A buffer that stores messages between producers and consumers. Messages are processed one by one, in order. Think of it as a to-do list for your services.
Event Sourcing
Storing every state change as an immutable event instead of just the current state. You can rebuild any past state by replaying events.
Microservices
An architecture where an application is split into small, independent services that communicate over the network. Each service owns its own data and can be deployed separately.
Monolith
A single, unified application where all features share the same codebase and deployment. Simpler to start with but harder to scale individual parts.
This page explains the idea. The "Command Pattern" 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 Command Pattern lessoncourse 1
From absolute beginner to principal engineer, drawn step by step.