We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design Masterclass · Microservices Architecture
Free preview: the first 2 parts of this 7-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Microservices Architecture
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
Think about a restaurant kitchen. When you order food, the waiter does not walk into the kitchen and start cooking. The waiter writes your order on a slip of paper, hands it to the kitchen, and walks away to serve other tables.
That order slip is a Command object. It contains everything needed to execute the request: what dish, what modifications, which table. The kitchen can process it immediately, queue it behind other orders, or reject it if an ingredient is unavailable. The waiter does not care how or when the kitchen processes it.
This decoupling is the Command pattern. You take a request, wrap it in an object with all the information needed to execute it, and pass that object around. The sender does not know who executes it. The executor does not know who sent it. The command itself can be stored, queued, logged, or undone.
Every task queue you have used is the Command pattern at scale. Celery, Bull, SQS. Every "undo" button in every application is the Command pattern. Every database write-ahead log is a sequence of serialized command objects. Stripe's keys rest on the same idea of a request as a self-contained unit that can be sent again safely. Stripe's API reference explains the mechanism: "Stripe's idempotency works by saving the resulting status code and body of the first request made for any given idempotency key, regardless of whether it succeeds or fails. Subsequent requests with the same key return the same result, including 500 errors." Note what that means: a retry is answered from the saved result, not executed a second time.
The Command pattern turns a request into a standalone object that contains all the information about the request. This lets you parameterize methods with different requests, delay or queue execution, and support undoable operations.
| Component | Role | Restaurant Analogy |
|---|---|---|
| Command | The request object with execute/undo methods | The order slip |
| Invoker | Triggers execution without knowing the details | The waiter |
| Receiver | The object that actually does the work | The kitchen |
| Client | Creates the command and sets up the receiver | The customer |
The critical insight: by turning a method call into an object, you gain the ability to store, transfer, queue, serialize, and undo that call. A regular function call is fire-and-forget. Once it runs, it is gone. A Command object is a tangible thing you can manipulate.
Redis uses the Command pattern for its protocol. Every write (SET, LPUSH, ZADD) is a command object that gets serialized to the AOF (append-only file) and replicated to followers. To recover after a crash, Redis replays the command log. That is the Command pattern enabling durability.