Loading...
System Design and AI Engineering, by Roni Das. 974 interactive lessons.
Start LearningIntermediate · Microservices Architecture
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.
In short
The strategy pattern is a behavioral design pattern that puts each version of an algorithm in its own class behind one interface. The code that uses it can then swap the algorithm at runtime. It replaces a growing if-else chain with small classes you can add without touching old code.
In short
The strategy pattern is a behavioral design pattern that puts each version of an algorithm in its own class behind one interface. The code that uses it can then swap the algorithm at runtime. It replaces a growing if-else chain with small classes you can add without touching old code.
This page is the free part.
₹499 in India$49 everywhere elseonce, for the whole course
The System Design course covers Strategy Pattern across a run of lessons, not one page. These 4 alone are about 71 minutes of step-by-step reading, every one with a quiz.
Swap algorithms at runtime without touching the code that uses them, polymorphism done right.
Abstract data access behind a clean interface, swap databases without touching business logic.
Pass requests along a chain of handlers, each handler decides to process it or pass it on.
Add responsibilities to objects dynamically by wrapping them, like middleware for your classes.
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 Strategy Patternpay once,
yours for life
A design pattern is a named, reusable answer to a problem that keeps coming up in code. The classic list of 23 patterns comes from the 1994 book by Gamma, Helm, Johnson and Vlissides, often called the Gang of Four. Strategy is one of them. It belongs to the behavioral group, the patterns about how objects share work.
The book states the intent of Strategy like this: define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from the clients that use it.
Here, an algorithm just means one way of doing a task. Encapsulate means to wrap it in its own class, so its details stay inside. Interchangeable means any one can stand in for another, because they all have the same method.
So the pattern has three roles. The context is the object that needs the work done. The strategy interface names the one method every version must have. The concrete strategies are the versions, one class each. The context holds a reference to the interface and calls it. It never knows which concrete class is behind it.
The lesson opens with a shipping cost function that every developer has written. It checks the shipping method with a chain of if-else branches. Standard costs the weight times 0.5. Express costs the weight times 1.5, plus 5. Overnight costs the weight times 3, plus 15. Then the business adds drone delivery, at the weight times 5, plus 25.
Each new method means opening the same function and adding one more branch. Every edit risks breaking the branches that already work. The function becomes, in the lesson's words, a magnet for changes.
This breaks the open/closed principle. That principle says code should be open for extension but closed for modification. In plain words, you should be able to add a feature by writing new code, not by editing tested code.
Strategy fixes this. Each shipping rule becomes its own class with one method, such as cost(weight). The calculator holds one of them and calls it. Adding drone delivery means writing one new class. The calculator and the other rules do not change.
The code below is the lesson's shipping calculator, rebuilt with Strategy. In JavaScript a strategy can be a small object with one function. In Java or C# you would declare an interface and write one class per strategy. The idea is the same. It was run with Node.js before it was added here.
shipping-strategy.js
// Each shipping method is its own strategy. Same interface: cost(weightKg).
const standard = { name: "standard", cost: (w) => w * 0.5 };
const express = { name: "express", cost: (w) => w * 1.5 + 5.0 };
const overnight = { name: "overnight", cost: (w) => w * 3.0 + 15.0 };
// The context. It holds a strategy and never asks which one it is.
class ShippingCalculator {
constructor(strategy) { this.strategy = strategy; }
setStrategy(strategy) { this.strategy = strategy; }
quote(weightKg) { return this.strategy.cost(weightKg); }
}
const calc = new ShippingCalculator(standard);
for (const s of [standard, express, overnight]) {
calc.setStrategy(s);
console.log(`${s.name}: ${calc.quote(4).toFixed(2)}`);
}
// A new method later is one new object. The calculator does not change.
const drone = { name: "drone", cost: (w) => w * 5.0 + 25.0 };
calc.setStrategy(drone);
console.log(`${drone.name}: ${calc.quote(4).toFixed(2)}`);Output, captured 2026-10-04 (node shipping-strategy.js)
standard: 2.00
express: 11.00
overnight: 27.00
drone: 45.00Look at quote(). It has no branch at all. It calls cost() on whatever strategy it holds. That is the whole trick. The choice of algorithm moved out of the calculator and into whoever calls setStrategy().
The lesson's main example is a checkout that takes payments in many countries. The context is a payment processor. The strategy interface has one method, processPayment(amount, currency). Each provider is a concrete strategy.
In the lesson's selection flow, a request arrives with the user's region. A lookup table maps the region to a provider. India goes to the Razorpay strategy, for UPI and net banking. The US and the EU go to the Stripe strategy. South-East Asia goes to the PayPal strategy, for regional wallets. A feature flag can also send 10 percent of traffic to a new provider, to test it.
Every path ends at the same call, strategy.processPayment(amount, currency). The checkout code has no if-else on the provider. The selection logic lives in a lookup table or a config layer, not inside the algorithms. To add a provider, you write one new class and one new row in the table.
Drawn from the lesson Strategy Pattern.
Three behavioral patterns look alike, because all three change behavior through polymorphism. Polymorphism means one method name that behaves differently depending on the object behind it. The lesson's comparison slide separates them by asking what triggers the change.
The lesson's practical test is short. 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. If the skeleton is fixed and only some steps vary by subclass, it is Template Method.
Strategy is also often compared with the Command pattern. A command is a request turned into an object, so it can wait in a queue and be undone. A strategy runs right away and records nothing. If you need a queue or an undo, you need Command.
The lesson gives clear rules. Use Strategy when you have several algorithms for the same task and need to switch between them. Use it to remove a large if-else or switch block. Use it when different customers, regions or plans need different behavior for the same operation. It also lets you test each algorithm on its own.
Skip it when there are only two algorithms and they are unlikely to change. A simple if-else is fine there. Skip it when the algorithms share so much state that each class would need dozens of parameters. And skip it when you add it only for future flexibility, with no real second strategy planned.
In modern languages a strategy does not have to be a class. A plain function passed as an argument does the same job. A sort function that takes a compare function is the strategy pattern in one line.
In distributed systems the pattern is everywhere, as the lesson points out. A load balancer picks a routing strategy: round-robin, least connections or consistent hashing. A rate limiter picks fixed window, sliding window or token bucket. A retry policy picks fixed delay or exponential backoff. Whenever the algorithm is configurable but the workflow stays the same, you are looking at Strategy.
For the other patterns in the same family, see design patterns. To work through the payment selection flow step by step, with a quiz at the end, open the Strategy Pattern lesson. It is the best next step after this page.
Payment checkout
The lesson's example: one processPayment(amount, currency) call. Razorpay, Stripe or PayPal is chosen by region, and a feature flag tests a new provider on 10 percent of traffic.
Load balancers
The routing job stays the same. Round-robin, least connections and consistent hashing are swappable strategies, per the lesson.
Rate limiters and retry policies
Fixed window, sliding window and token bucket are strategies for one limiter. Fixed delay and exponential backoff are strategies for one retry loop.
Serialization
The lesson lists JSON, Protobuf and Avro as strategies behind one encode and decode step.
The strategy design pattern defines a family of algorithms, puts each one in its own class, and makes them interchangeable behind one interface. The code that uses the algorithm holds a reference to the interface and calls it, without knowing which version runs. You can swap the version at startup through config, or at runtime by user choice.
Both delegate work to an interchangeable object. In Strategy, someone outside picks the object, and strategies do not know about each other. In State, the object switches its own state object when events happen, and states often know which state comes next. A circuit breaker moving from CLOSED to OPEN is State, not Strategy.
They are the patterns in the 1994 Gang of Four book, in three groups. Creational: Abstract Factory, Builder, Factory Method, Prototype, Singleton. Structural: Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Proxy. Behavioral: Chain of Responsibility, Command, Interpreter, Iterator, Mediator, Memento, Observer, State, Strategy, Template Method, Visitor.
The Gang of Four sort their patterns into creational, structural and behavioral. Creational patterns are about how objects get created. Structural patterns are about how objects are put together. Behavioral patterns, which include Strategy, are about how objects divide work and talk to each other.
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.
State Pattern
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.
Command Pattern
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.
Load Balancer Algorithm
The strategy a load balancer uses to distribute requests. Round-robin, least-connections, weighted, IP-hash, and random are common algorithms, each with different trade-offs.
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 "Strategy 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 Strategy Pattern lessoncourse 1
From absolute beginner to principal engineer, drawn step by step.