If you're interviewing for backend roles, chances are you'll be asked about design patterns. Interviewers aren't looking for textbook definitions—they want to know when you'd use a pattern and why.

Here are the five patterns I think every Java developer should know.

1. Singleton Pattern

The Singleton pattern ensures only one instance of a class exists throughout the application.

Real World Example

Think of a printer in an office. You don't want every employee creating a new printer. Everyone shares the same one.

Java Example

public class DatabaseConnection {
 
    private static final DatabaseConnection INSTANCE =
            new DatabaseConnection();
 
    private DatabaseConnection() {}
 
    public static DatabaseConnection getInstance() {
        return INSTANCE;
    }
}

Usage

DatabaseConnection db = DatabaseConnection.getInstance();

Where you'll see it

• Spring Beans (Singleton scope by default)
• Logger instances
• Configuration Managers
• Cache Managers

Interview Tip

Singleton is useful when creating multiple objects is expensive or unnecessary.

2. Factory Pattern

Instead of creating objects directly with new, delegate object creation to a factory.

Real World Example

Ordering coffee.

You don't make the coffee yourself.

You simply ask:

Give me a Cappuccino.

The coffee machine creates the correct object.

Java Example

interface Notification {
    void send();
}
 
class EmailNotification implements Notification {
    public void send() {
        System.out.println("Email Sent");
    }
}
 
class SMSNotification implements Notification {
    public void send() {
        System.out.println("SMS Sent");
    }
}
 
class NotificationFactory {
 
    static Notification getNotification(String type){
 
        if(type.equals("EMAIL"))
            return new EmailNotification();
 
        return new SMSNotification();
    }
}

Usage

Notification notification =
    NotificationFactory.getNotification("EMAIL");
 
notification.send();

Where you'll see it

• Spring BeanFactory
• JDBC Drivers
• Payment Gateway integrations
• Notification systems

Interview Tip

Whenever object creation becomes complicated, Factory is usually the answer.

3. Strategy Pattern

Instead of writing multiple if-else statements, encapsulate each algorithm into its own class.

Bad

if(payment.equals("CARD")){
    ...
}
else if(payment.equals("UPI")){
    ...
}
else if(payment.equals("PAYPAL")){
    ...
}

Better

interface PaymentStrategy{
    void pay();
}
 
class CardPayment implements PaymentStrategy{
    public void pay(){
        System.out.println("Paid by Card");
    }
}
 
class UpiPayment implements PaymentStrategy{
    public void pay(){
        System.out.println("Paid by UPI");
    }
}

Usage

PaymentStrategy payment =
        new UpiPayment();
 
payment.pay();

Real World Example

Google Maps.

Different navigation strategies.

• Car
• Bike
• Walking

Same problem.

Different algorithm.

Where you'll see it

• Payment Methods
• Sorting Algorithms
• Shipping Charges
• Authentication Providers

Interview Tip

Whenever you see multiple interchangeable algorithms, think Strategy.

4. Observer Pattern

One object changes.

Multiple objects automatically receive updates.

Real World Example

You subscribe to a YouTube channel.

Whenever a video is uploaded,

every subscriber gets notified.

Java Example

interface Observer{
    void update();
}
 
class User implements Observer{
 
    public void update(){
        System.out.println("Notification received");
    }
}
 
class Channel{
 
    List<Observer> observers = new ArrayList<>();
 
    void subscribe(Observer observer){
        observers.add(observer);
    }
 
    void uploadVideo(){
 
        for(Observer observer : observers){
            observer.update();
        }
    }
}

Where you'll see it

• Kafka Consumers
• RabbitMQ
• Event Listeners
• Spring Events
• WebSockets

Interview Tip

Whenever one event triggers many actions, Observer is a great fit.

5. Builder Pattern

Useful when an object has many optional parameters.

Bad

User user =
new User(
    "Jitesh",
    24,
    "India",
    true,
    false,
    ...
);

Nobody remembers what every parameter means.

Better

User user = User.builder()
        .name("Jitesh")
        .age(24)
        .country("India")
        .isPremium(true)
        .build();

Real World Example

Ordering a pizza.

You choose:

• Size
• Cheese
• Toppings
• Crust

The final pizza is built only after you've selected everything.

Where you'll see it

• Lombok @Builder
• Spring Boot configuration objects
• Immutable DTOs
• Request objects

Interview Tip

Builder improves readability and avoids constructors with dozens of parameters.

Which Ones Matter Most?

If you're interviewing for backend roles, this is the order I'd study them:

1. Strategy
2. Factory
3. Builder
4. Singleton
5. Observer

Together, these patterns cover the majority of design pattern questions asked in Java and Spring Boot interviews.

The biggest takeaway is this:

Design patterns are not about memorizing class diagrams. They're about recognizing recurring problems and applying proven solutions that make your code easier to extend, test, and maintain.