The Design Patterns That Keep Showing Up in LLD Interviews

Ask a candidate to define the Singleton pattern and most rattle it off in five seconds flat. Ask them why a payment service handling three regional providers probably shouldn't use one, and the room goes quiet. That gap, reciting a pattern versus knowing when it actually breaks something, is what most design patterns interview questions are testing in 2026, not whether you memorized a UML diagram, and it's exactly the kind of live judgment call our AI Interview Copilot is built to help you reason through once you're actually in the room.

The three buckets, and the patterns interviewers actually reach for

The original Gang of Four book split 23 patterns into three buckets: creational, structural, and behavioral. Refactoring.Guru's public catalog groups them the same way and is still the cleanest free reference for the full list, if you want to see all 23 laid out with diagrams (Refactoring.Guru, Design Patterns Catalog). Most design patterns interview questions in an actual LLD round don't touch anywhere near 23 patterns. In practice, eight or nine patterns cover something close to 90% of what actually gets asked, and interviewers care a lot less about which bucket a pattern sits in than whether you can explain what breaks without it. If you want a quick self-check on where you stand before you get there, LastRoundAI's free career tools include a couple of short assessments worth running first.

Category	What it solves	Patterns interviewers actually ask about
Creational	How objects get built	Singleton, Factory Method, Abstract Factory, Builder
Structural	How objects fit together	Adapter, Decorator, Facade
Behavioral	How objects talk to each other	Observer, Strategy

That's eight patterns out of 23, not all of them. I'd personally skip memorizing Visitor and Flyweight for most SDE-2 and SDE-3 loops. I've seen them come up maybe twice across a couple years of interview prep conversations, and both times the interviewer was fine with "I'd just use a loop here instead."

Creational patterns: how systems build the things they need

Singleton restricts a class to exactly one instance and gives every caller a shared access point to it. The classic real-world version is a country's central bank: you don't want fifty regional banks each setting their own interest rate independently, you want one source of truth. In code, that usually shows up as a config loader, a connection pool, or a logging sink.

class ConfigLoader:
    _instance = None

    def __new__(cls):
        if cls._instance is None:
            cls._instance = super().__new__(cls)
            cls._instance.settings = {}
        return cls._instance

That's the whole pattern, maybe eight lines. The interesting part isn't the code. It's what happens when two threads call ConfigLoader() at the exact same moment before _instance gets set. That race condition is a real follow-up question, not a hypothetical, and it's usually the first sign an interviewer wants to see if you actually understand what you wrote.

Factory Method and Abstract Factory both decouple object creation from the code that uses the object. Factory Method hands back one product without the caller needing to know the exact subclass, the way a recruiter routes a candidate to a phone-screen interviewer or a system-design interviewer without the candidate needing to know which interviewer class got instantiated. Abstract Factory goes a step further and produces whole families of related objects that have to match, the way an IKEA showroom sells a matched dining set (table plus four chairs) and would never let you mix pieces across two different collections.

Builder solves a narrower, more annoying problem: constructors with too many optional parameters, sometimes called the telescoping constructor problem. Instead of a constructor with twelve boolean flags, you build the object step by step. Ordering a burger with a dozen possible customizations at a counter works the same way, you add instructions one at a time rather than filling out a form with twelve checkboxes up front.

Structural patterns: making pieces that don't fit, fit

Adapter bridges an existing interface to the one a client expects, without touching the original code. A travel plug adapter is the textbook analogy, but the version that shows up in interviews is closer to wrapping a legacy vendor API that only speaks XML behind a class that emits JSON, so the rest of the codebase never has to know the mismatch exists.

Decorator attaches new responsibility to an object at runtime without changing its class or triggering a subclass explosion. A coffee order is the standard example and it's a good one: base espresso, wrapped in milk, wrapped in caramel, wrapped in whipped cream, each wrapper adding cost and behavior on top of an object whose original class never changes.

Facade hides a tangle of subsystem calls behind one simple entry point. Turning a car key triggers the fuel pump, the starter motor, and the ignition coil, but the driver only ever interacts with one action. Facade's failure mode is worth knowing too: it can hide too much. When a caller needs to bypass the simplified path for one edge case and the facade doesn't expose a way to do that, you end up with an ugly workaround bolted onto the outside, or a rewrite.

Behavioral patterns: Observer and Strategy

Observer handles one-to-many notification. A YouTube channel's subscribers all get notified when a new video drops, and the channel never has to know anything about who's subscribed or how many there are. This is the backbone behind most pub-sub systems, UI event listeners, and MVC view updates, so recognizing Observer under an unfamiliar prompt is a genuinely useful skill.

Strategy swaps out an algorithm at runtime instead of growing an if-else chain forever.

class PaymentStrategy:
    def pay(self, amount):
        raise NotImplementedError

class CreditCard(PaymentStrategy):
    def pay(self, amount):
        return f"Charged ${amount} to card"

class Checkout:
    def __init__(self, strategy: PaymentStrategy):
        self.strategy = strategy

    def complete(self, amount):
        return self.strategy.pay(amount)

Add PayPal or Apple Pay later and you write a new class. You don't touch Checkout at all, which is really the Open/Closed Principle showing up with a different name on it.

Where this actually shows up in an LLD round

Interviewers rarely say "implement the Observer pattern." They say "design a notification system for a ride-share app" or "design a parking lot" or "design a rate limiter," and the pattern is the thing you're expected to reach for without being told its name. Design a parking lot and Factory tends to surface when you're deciding how vehicles get matched to slots. Design a notification system and Observer is almost always the backbone. Design a logging framework and Singleton, or its safer cousin, a single instance passed in through a constructor, comes up constantly, which is also exactly where it gets misused most.

Our companion breakdown of low-level design interview questions walks through eight of these prompts end to end, clarifying questions through class diagrams, if you want the fuller LLD picture beyond just the pattern names. Amazon's SDE-2 loop is a good concrete example of where this gets tested in the room: system design and pattern-heavy follow-ups both show up there, and our Amazon SDE-2 interview questions breakdown covers what candidates actually report being asked. Landing that loop in the first place usually starts with a resume that gets you shortlisted, which is what LastRoundAI's resume builder is built for.

On LastRoundAI's mock interview reviews for backend and LLD rounds, the score gap we keep seeing isn't pattern recall. It's candidates who can code Singleton from memory but stumble the moment we ask why two threads calling getInstance() at the same time is a problem, or what they'd do instead inside a stateless microservice. Naming the pattern is table stakes. Defending the trade-off, out loud, under a follow-up question, is the actual interview.

The Singleton problem, and how patterns tie back to SOLID

Singleton is the pattern interviewers love to attack, and for good reason. Miško Hevery, a Google engineer, argued back in 2008 that singletons hide dependencies, classes reach into global state without declaring it anywhere in their constructor, which makes unit testing painful and couples code that had no business being coupled (Google Testing Blog, "Root Cause of Singletons," 2008). That critique is almost two decades old now and it still holds up. If you reach for Singleton in an interview, the strong move is naming the cost out loud, harder to test, harder to parallelize, a magnet for hidden state, and then explaining why you're accepting that cost anyway, or why you'd inject a single instance through a constructor instead and get the same guarantee without the global access point.

Most of the patterns above are really SOLID principles wearing a name. Strategy and Observer are the Open/Closed Principle in practice: you add a new payment method or a new subscriber without touching existing code. Factory and Abstract Factory lean on Dependency Inversion, since the calling code depends on an interface, not a concrete class. Decorator and Adapter both avoid modifying existing classes, which is Open/Closed again from a different angle. If you haven't looked at SOLID directly yet, our SOLID principles breakdown is the shorter, more foundational read this post is quietly assuming you've done.

Sample design patterns interview questions

What's the difference between Factory Method and Abstract Factory?

Factory Method creates one product through a single overridden method, usually via subclassing. Abstract Factory creates a whole family of related products through one interface, so a UI toolkit's WindowsFactory and MacFactory each produce a matched button, checkbox, and scrollbar that never get mixed across platforms. If the interviewer only mentions one product type, they probably want Factory Method.

When would you reach for Builder instead of a constructor with optional parameters?

Once a constructor needs more than four or five optional parameters, or the object has to be built across several steps with validation in between, Builder wins. A classic interview tell: if the prompt says "some fields are required, some optional, and order matters," that's Builder, not a constructor with a dozen boolean flags.

Why do interviewers push back on Singleton so often?

Because it's the pattern most likely to be misused. Singleton makes sense for something that genuinely must be unique and largely stateless, like a logging sink. It stops making sense the moment you need to test the class in isolation, run it safely across threads, or scale the service horizontally, since a singleton in one process instance doesn't coordinate with a singleton in another process at all.

How is Adapter different from Decorator, since both wrap an object?

Adapter changes an interface so two incompatible systems can talk to each other. Decorator keeps the same interface and adds behavior on top of it. Translating one shape into another, XML into JSON, an old API into a new one, is Adapter. Layering extra behavior onto an object that already speaks the right interface, adding logging, caching, or compression around a service call, is Decorator.

Design a system that notifies multiple services when an order ships. Which pattern fits?

Observer. The order service publishes a single "shipped" event, and each interested party, email, SMS, the warehouse dashboard, subscribes independently without the order service knowing who's listening or how many. This is also the shape behind most pub-sub and event-driven systems, so naming Observer here signals you understand the broader pattern too, beyond this one prompt.

When would you choose Strategy over a long if-else chain?

The moment a new "type" gets added often enough that you keep editing the same conditional every few weeks. Strategy moves each branch into its own class, so adding PayPal or Apple Pay as a payment option means writing a new class, not touching checkout logic that already works and is already tested.

What does Facade solve, and where does it become a liability?

Facade hides a subsystem's internal complexity behind one clean method, like a single startEngine() call that quietly handles the fuel pump, starter motor, and ignition coil. It becomes a liability when a caller needs to bypass the simplified path for one edge case and the facade doesn't expose a way to do that, which forces an ugly workaround or, eventually, a rewrite.

How do design patterns relate to the SOLID principles?

Most of the patterns above are SOLID principles with a name attached to them. Strategy and Decorator both extend behavior without modifying existing code, which is Open/Closed. Factory and Abstract Factory push callers to depend on interfaces rather than concrete classes, which is Dependency Inversion. An interviewer asking this question usually wants to hear that connection stated directly, rather than a recap of each pattern's mechanics.

Can you combine multiple patterns in one design?

Yes, and interviewers expect it once the round goes beyond a single class. A payment gateway is a common example: Factory decides which provider class to instantiate, Strategy defines how each provider processes a charge, and Observer notifies downstream services once the payment settles. Naming all three, and explaining why each one earns its place, is a stronger answer than picking just one and stopping there.

What's a red flag when a candidate over-uses patterns in an interview?

Reaching for a pattern before there's a real problem to solve. Introducing a Factory for a class that will only ever have one implementation, or wrapping something in a Decorator that never needs runtime flexibility, reads as pattern-matching from a study guide rather than actual design judgment. I'd honestly rather hear "a plain class works fine here, I don't need a pattern yet" than a Singleton bolted onto something that never needed one.

Is it okay to not remember every pattern's exact name in an interview?

Mostly, yes. I don't think perfect terminology recall matters as much as candidates assume. If you describe "a class that hands out shared config" and forget the word Singleton for a second, most interviewers will let it go, or supply the name themselves, as long as the underlying design reasoning is sound. Where it stops being okay is using the wrong pattern's mechanics while using the right pattern's name.

Reciting nine patterns off a flashcard deck gets you through the first thirty seconds of an LLD round. The rest of it is defending the trade-off out loud, under a bit of pressure, while someone asks what happens if a fourth payment provider gets added next month. That's the part most candidates skip practicing, and it's exactly what LastRoundAI's voice mock interviews are built to drill, live follow-up questions included. Pick the one pattern you're weakest at defending, not naming, and start there.