What are software design patterns, and when do you use them?

In this article

1. Before you start
2. Why interviewers ask this
3. Software design patterns from first principles
4. Worked example
5. Trade-offs and edge cases
6. How to answer it in an interview
7. Common mistakes
8. Follow-up questions
9. Sources

Before you start

Software design patterns are one topic in the system design interview guide, and they work inside a program, not between servers.

Why interviewers ask this

The question usually arrives as "what is a design pattern?" or "when would you use Strategy or Observer?" It looks like trivia, but it separates candidates who memorized names from candidates who can reason about change.

A weak answer lists pattern names, or says a pattern is "a piece of code to reuse". A strong answer says a pattern is a described solution to a recurring problem, names the problem it solves, and states what it costs. A Staff-level answer adds the judgment: which pattern is overkill here, which one a language feature already replaces, and how the choice would be tested.

Interviewers reach this topic from many directions, such as a payment system design round, where a candidate must decide how to swap payment providers, or a general backend interview. A clear answer shows you design for change instead of reacting to it.

Software design patterns from first principles

Design pattern

A design pattern is a named, reusable description of a solution to a problem that recurs in software design, giving the roles, how they interact and the trade-offs, so that you adapt it to your code instead of copying it.

Strategy pattern

The Strategy pattern is a way to make one step of a program swappable by putting each version of that step behind a common interface, so the caller picks a version without knowing how it works.

Observer pattern

The Observer pattern is a way to let one object announce events to any number of listeners that register with it, so the announcer does not need to know who is listening.

In plain words

Think of the dovetail joint in woodworking. Carpenters have a name for it. The name tells you the problem it solves: joining two boards so they do not pull apart. Every carpenter cuts it a little differently, to fit the wood in front of them. The analogy breaks in one place. A joint has a physical shape, but a pattern is a design idea, and it can be wrong for your code.

In one precise sentence, a design pattern is a named arrangement of roles, such as a caller and an interchangeable part, that is known to handle one kind of change well. The idea came from architecture: the classic book credits the architect Christopher Alexander. The software catalogue was written in 1994 by Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides, known as the Gang of Four.

Step 1: A pattern names a problem and a solution

A design pattern names a recurring problem and a reusable solution. The name matters as much as the solution: saying "use a factory here" gives a team a shared word for a whole arrangement. The book describes each pattern with four elements: a name, the problem, the solution and the consequences.

Input: a problem you have met before, such as "I need to choose between several ways of doing this". Output: a name, the roles involved and the trade-off. A pattern is not a library, a framework or a snippet. Two teams can both apply Strategy and write entirely different code. You now know what a pattern is; next is how the catalogue is organized.

Step 2: Patterns come in three families

The classic catalogue splits into three families, each answering one question. Creational patterns control how objects are made. Structural patterns control how parts fit together. Behavioral patterns control who does what and when.

Input: the question you are asking about your design. Output: the family to look in. If the pain is "construction is messy", look at creational patterns such as Factory Method or Builder. If the pain is "these two parts do not fit", look at structural ones such as Adapter or Decorator. If the pain is "behavior must change or fan out", look at behavioral ones such as Strategy, Observer or Command. Choosing a family narrows the search from 23 to a handful.

Step 3: Pick the pattern by what varies, not by its name

Pick a pattern by what varies, not by its name. Start from the thing that will change, such as the pricing rule, the payment provider or the set of listeners, and ask which pattern isolates exactly that.

Input: a list of the parts of your design that you expect to change. Output: one chosen pattern, or none. If a discount rule changes, the varying thing is an algorithm, which points to Strategy. If many parts must react to one event, the varying thing is the set of listeners, which points to Observer. If nothing varies, no pattern is needed.

This is also the answer to the interview trap. You remove a pattern when nothing it isolates has ever varied: the indirection costs reading time and buys nothing.

Step 4: Hide the variation behind an interface and check the cost

Hiding the varying part behind an interface is how most patterns work, and it lowers coupling. Coupling is how much one piece of code must know about another.

Input: the varying part and the code that uses it. Output: a caller that depends on the interface only. The cost is one more layer to read and one more name to learn. A first-class function is a function that can be stored in a variable and passed as an argument; in languages that have them, a plain function often does the job of a small Strategy class. Check the cost before you commit: with two stable variants a simple conditional may be clearer than a pattern.

1 · Name the problem2 · Find the family3 · Find what varies4 · Interface and costReplay

Step-by-step description

1. A pattern names a recurring problem and a solution.
2. Creational, structural or behavioral.
3. Pick the pattern by what varies.
4. Hide the variation, then check the cost.

• A design pattern names a recurring problem and a reusable solution.
• Pick a pattern by what varies, not by its name.

Worked example

A shopping cart has to apply a discount, and the rule will change. The illustrative cart holds three items priced 40, 25 and 35, so the subtotal is 100.¹

def no_discount(total):   return total
def ten_percent(total):   return total * 0.9
def flat_fifteen(total):  return total - 15

def checkout(prices, discount):
    return discount(sum(prices))

The checkout function never mentions a specific rule. It receives the rule as an argument, which is the Strategy pattern written with first-class functions: each rule is one strategy and the caller picks one. With the three rules the totals are 100, 90 and 85, and adding a fourth rule changes no existing line.¹

The Observer pattern traces the same way. One subject announces 2 events to 3 registered listeners, so 6 deliveries happen; when a fourth listener registers, the same 2 events cause 8 deliveries, and the subject's code is unchanged.¹

In the book's catalogue, the 23 patterns split into creational, structural and behavioral families. Counting the pattern names transcribed from it in the script gives 5 creational, 7 structural and 11 behavioral, which total 23.¹ Behavioral patterns are the largest family, with 11 of the 23. Creational has 5 and structural has 7.

Text description of the diagram

• Creational patterns control how objects are made.
• Structural patterns control how parts fit together.
• Behavioral patterns control who does what and when.

Text description of the diagram

• Behavioral patterns are the largest family, with 11 of the 23.
• Creational has 5 and structural has 7.

Trade-offs and edge cases

Patterns trade simplicity today for flexibility later. Each one adds a layer of indirection, so using more of them does not make a design better; a pattern with one variant is overhead.

Patterns also age with languages. The classic catalogue was written for class-based object-oriented languages, and some patterns shrink when a language has first-class functions. Norvig (1996) reports that 16 of the 23 patterns are either unnecessary or simpler in Lisp or Dylan. Strategy, as the worked example shows, and Command likewise can become a function argument. Treat that as a trade-off to state, not a rule to recite.

Singleton, which allows only one instance of a class, is the pattern most often challenged. It behaves like global state, which makes tests harder because one test can leave data behind for the next. Passing the shared object in as an argument still creates one instance, but nothing hides the dependency. In current practice, a dependency-injection container (a tool that creates shared objects and hands them to the code that needs them) or a language-level singleton, such as the Kotlin object declaration, often replaces a hand-written Singleton.

Finally, the phrase is used in two senses. This page is about object-level patterns inside a program. Retry, circuit breaker, saga and similar designs are patterns between services, a different family covered in the system design guide. Release patterns such as canary rollouts are another between-services topic: see deployment strategies. Saying which sense you mean is itself a strong signal in an interview.

How to answer it in an interview

The spoken structure: define it in one sentence, say how you choose by what varies, then state the cost and one example of when you would not use it.

Common mistakes

• "A design pattern is a library you import." (wrong) A pattern is a described arrangement, not code. "It is a blueprint I adapt to my code." (right)
• "I would use as many patterns as possible to show good design." (wrong) Every pattern adds indirection. "I add one when something varies and I can name what varies." (right)
• "Singleton is the right way to share a database connection." (wrong) It hides a dependency and complicates tests. "I create one instance and pass it in." (right)
• "Design patterns means retry and circuit breaker." (wrong) Those are service-level patterns. "I will say whether I mean object-level or distributed patterns." (right)

Follow-up questions

What are the three types of design patterns?

Creational, structural and behavioral: creational patterns control how objects are made, structural ones how parts fit together, and behavioral ones who does what and when.

What is the difference between Strategy and State?

Both put behavior behind an interface. In Strategy the caller chooses the version and it usually stays put; in State the object switches versions itself as its own condition changes.

Is MVC (model-view-controller) a design pattern?

It is an architectural pattern for organizing a whole application into data, display and input handling, not one of the 23 classic patterns. It sits at a larger scale than Strategy or Observer.

What are the most commonly used design patterns?

No reliable usage count exists, so take this as judgment, not statistics. In everyday code people meet Strategy, Observer, Adapter, Decorator, Factory Method and Builder often, because change in behavior, events, interfaces and construction is common. Singleton is also common, and also the most criticized.

Do software design patterns apply to distributed systems?

The object-level ones apply inside each service, and Observer has a network cousin in the webhook, where a server notifies registered listeners over the network. Patterns between services, such as retries or sagas, are a separate family.

Do you still need design patterns in Python or JavaScript?

You still need the ideas, but not always the classes. Because functions can be passed around, Strategy and Command often shrink to a function argument. Patterns such as Adapter and Decorator remain useful. An Adapter can wrap an older service behind the application programming interface your clients expect, and a Decorator can add logging around each call of a representational state transfer (REST) service; see the REST application programming interface (API) interview questions.

Sources

1. Design Patterns: Elements of Reusable Object-Oriented Software — Addison-Wesley (Gamma, Helm, Johnson, Vlissides), 31 Oct 1994
2. Design Patterns in Dynamic Languages (Norvig) — Peter Norvig, 1 May 1996
3. Software design pattern — Wikipedia (pointer for the definition), 26 Oct 2026