Loading...
System Design and AI Engineering, by Roni Das. 974 interactive lessons.
Start LearningIntermediate · Microservices Architecture
A creational design pattern where one method or class decides which concrete object to build, so the calling code asks for an object by type or config instead of calling a constructor directly.
In short
The factory pattern is a creational design pattern where one method or class decides which concrete object to build, so the calling code asks for an interface instead of calling a constructor. Creation lives in one place, and swapping an implementation changes the factory, not every caller.
In short
The factory pattern is a creational design pattern where one method or class decides which concrete object to build, so the calling code asks for an interface instead of calling a constructor. Creation lives in one place, and swapping an implementation changes the factory, not every caller.
This page is the free part.
₹499 in India$49 everywhere elseonce, for the whole course
The System Design course covers Factory Pattern across a run of lessons, not one page. These 4 alone are about 70 minutes of step-by-step reading, every one with a quiz.
Delegate object creation to a factory, decouple what you use from how it's built.
Ensure a class has only one instance, the most loved and hated design pattern in software.
Istio vs. Linkerd vs. Cilium, choosing and deploying a service mesh in practice.
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 Factory Patternpay once,
yours for life
A design pattern is a named, reusable answer to a problem that keeps coming back in code. The factory pattern answers this one: who decides which class to create?
Without a factory, the code that needs an object also builds it. It writes something like new RazorpayClient(). That line ties the caller to one concrete class. A concrete class is a real class you can create, as opposed to an interface, which only lists the methods a class must have.
With a factory, the caller asks for what it needs by role: "give me a payment client". A separate piece of code, the factory, picks the concrete class. It can choose based on region, configuration, a feature flag or a test mode. The caller never learns which class it got. It only uses the interface.
The factory family belongs to the creational patterns, the group of patterns about how objects get made. See creational design patterns for the whole group, and design patterns for the full catalogue.
The lesson opens with a story. A startup in Bangalore had written new RazorpayClient() in 47 files. Then they needed Stripe for international customers. Every one of those 47 files had to change, because each one had its own creation logic. The lesson reports three months of refactoring and dozens of bugs.
The real mistake was mixing two ideas. "I need a payment processor" is what the code wanted. "Give me a Razorpay instance" is how it got one. The factory pattern keeps those two ideas apart.
The lesson's comparison table shows what changes once a factory is in place:
The lesson walks one request through a payment factory. The checkout code never names Stripe or Razorpay.
Drawn from the lesson Factory Pattern.
Look at where the arrows go. Checkout has two arrows: one to the factory and one to the interface. It has none to StripeClient or RazorpayClient. That missing arrow is the whole point. Serving India with Razorpay becomes a config change, not a code change.
People say "factory pattern" for three different things. They are worth telling apart, because interview questions and older books use the names strictly.
The lesson also compares Builder, a fourth creational pattern. Builder assembles one complex object step by step, with optional parts, like an HTTP request with a URL, headers and a timeout. It is not a factory, but it solves a nearby problem.
One short way to remember the split: a Simple Factory branches, a Factory Method subclasses, and an Abstract Factory makes whole matching sets.
The lesson gives a decision path. Start with the simplest option and add a pattern only when the problem forces it.
Every layer of indirection costs readability. Indirection means the reader must jump to another place to see what really happens. So justify each factory with a real need.
The lesson names overuse as the biggest mistake. Picture a UserServiceFactory that only ever returns UserService. There is no test double, no second implementation and no plan for one. That factory adds a layer and buys nothing. The lesson calls this ceremony, not clean architecture.
Skip the factory when there is only one implementation and no realistic second one. Skip it when creation is a plain new Thing(). Skip it too when a dependency injection framework already chooses implementations for you. Dependency injection means the framework builds objects and passes them in, so your code never calls the constructor at all.
Use a factory when you do not know the concrete class ahead of time. Use one when creation needs complex setup you do not want to repeat. And use one when you must swap implementations for tests, experiments or regions.
The factory pattern often sits next to the singleton pattern, which the singleton lesson covers just before this one. It also pairs with the strategy pattern: a factory picks which strategy object to create, and the strategy does the work.
To work through the dispatch sequence, the comparison table and the quiz, the Factory Pattern lesson is the next step.
Payment providers by region
The lesson's main example: a checkout asks a PaymentFactory for a PaymentClient, and config decides between Stripe for the US and Razorpay for India.
Multi-cloud bundles
The lesson's Abstract Factory example: one factory builds S3, SQS and DynamoDB, another builds GCS, Pub/Sub and Firestore, so the parts always match.
Factory Method is a creational pattern from the Gang of Four book. A base class declares a method that creates an object, and subclasses override that method to decide which concrete class to return. The caller works with the base class and the product interface, so it never names the concrete class.
To keep the decision about which class to build in one place. Callers depend on an interface, so swapping a provider, adding a type or returning a mock in tests changes the factory and nothing else. In the lesson's example this turns a 47 file change into a one method change.
A Simple Factory is one method with a conditional that picks a class. A Factory Method lets subclasses override a creation method to choose the class. An Abstract Factory creates whole families of related objects that must match, such as all the parts for one cloud provider.
They are the patterns catalogued in the 1994 Gang of Four book, Design Patterns. The book sorts them into three groups: creational patterns such as Factory Method and Singleton, structural patterns such as Adapter and Facade, and behavioral patterns such as Strategy and Observer. The design patterns glossary page lists them by group.
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.
Creational Design Patterns
The family of design patterns about how objects get created: Singleton, Factory Method, Abstract Factory, Builder and Prototype. They hide the construction details from the code that uses the object.
Singleton Pattern
A creational design pattern that makes sure a class has exactly one instance and gives the whole program one shared way to reach it, used for things like a connection pool or a config object.
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.
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 "Factory 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 Factory Pattern lessoncourse 1
From absolute beginner to principal engineer, drawn step by step.