Facade Pattern

1The problem it solves#

A subsystem of five or six classes is powerful but hard to call correctly. Each class does one job, so getting something useful done means talking to all of them, in the right order, with the right data passed between them.

Picture a "place an order" flow in an online store. One order needs four steps, in sequence:

1. Check the item is in stock (InventoryService)
2. Charge the card (PaymentService)
3. Book a courier (ShippingService)
4. Email a receipt (NotificationService)

Now spread that four-step dance across your codebase. Say the order logic lives in 3 controllers, 2 background jobs, and a dozen tests:

• That is the same 4-step sequence copy-pasted in 17 places.
• Add a fraud check between steps 2 and 3, and you hunt through all 17 callers to patch every one.
• You will miss one. You always miss one.

The real pain is coupling. Every caller depends on 4 classes plus the exact order they run in:

• That is 4 reasons every caller might break when the subsystem changes.
• It is a direct Single Responsibility Principle violation: the controller now owns both "handle the HTTP request" and "know the order-placement choreography."

2The idea (mental model)#

Think of the front desk at a hotel. You want a late checkout, a taxi, and your bags sent up:

• You do not call housekeeping, then the garage, then the bell desk yourself.
• You talk to the front desk and say what you want. They coordinate the rest.
• The front desk does not replace housekeeping or the garage. Those still exist and still do the real work.
• It just gives you one number to call and hides the org chart.

That is the whole pattern. A Facade is a class that wraps a complicated subsystem and exposes a small, friendly method or two that do the common thing. The subsystem classes stay exactly as they are. You are only adding a simpler way in.

Two things worth locking in:

• It adds no new behavior of its own. It orchestrates existing behavior. If it starts computing things, it has stopped being a Facade.
• It does not block direct access. If an advanced caller needs a subsystem class directly, they still can. The Facade is a convenience, not a wall.

3Structure#

The cast is small. Three roles, and only one arrow direction matters:

• Subsystem classes do the real work.
• The Facade is the simple front.
• The Client wants the job done and talks only to the Facade.

The Facade holds references to the subsystem classes and delegates to them. Nothing inherits anything: this is composition, not inheritance. The Facade is composed of the pieces it coordinates, which is "favor composition" in practice.

Here is the same thing as a runtime flow, which is what an interviewer usually wants you to walk through:

4Implementation in Java#

Keep the subsystem classes honest but minimal. Imagine each one has real logic inside.

// --- Subsystem classes. Each knows one job and nothing about the others. ---

class InventoryService {
    boolean reserve(String itemId) {
        System.out.println("Reserved " + itemId);
        return true;
    }
}

class PaymentService {
    boolean charge(String cardToken, double amount) {
        System.out.println("Charged " + amount);
        return true;
    }
}

class ShippingService {
    String schedule(String itemId, String address) {
        System.out.println("Courier booked to " + address);
        return "TRK-" + itemId.hashCode();
    }
}

class NotificationService {
    void sendReceipt(String email, String trackingId) {
        System.out.println("Receipt to " + email + ", track " + trackingId);
    }
}

Now the Facade. One method, one clear job, all the orchestration hidden inside it.

class OrderFacade {

    private final InventoryService inventory = new InventoryService();
    private final PaymentService payment = new PaymentService();
    private final ShippingService shipping = new ShippingService();
    private final NotificationService notifier = new NotificationService();

    // The client calls only this.
    public String placeOrder(String itemId, String cardToken,
                             double amount, String address, String email) {

        if (!inventory.reserve(itemId)) {
            return "FAILED: out of stock";
        }
        if (!payment.charge(cardToken, amount)) {
            return "FAILED: payment declined";
        }

        String trackingId = shipping.schedule(itemId, address);
        notifier.sendReceipt(email, trackingId);

        return "CONFIRMED: " + trackingId;
    }
}

And the client, which is now blissfully dumb:

public class Store {
    public static void main(String[] args) {
        OrderFacade orders = new OrderFacade();

        String result = orders.placeOrder(
            "BOOK-42", "tok_abc", 499.0,
            "12 MG Road", "buyer@example.com"
        );

        System.out.println(result);
    }
}

Notice what the client does not know:

• That there are four services at all.
• The order they run in.
• That stock is checked before the card is charged.

The day I add a fraud check, I touch one file: the Facade. One file instead of 17.

The fix is constructor injection. Pass the services in so you can swap mocks in tests:

class OrderFacade {
    private final InventoryService inventory;
    private final PaymentService payment;
    // ... accept the rest via constructor too

    OrderFacade(InventoryService inventory, PaymentService payment /* ... */) {
        this.inventory = inventory;
        this.payment = payment;
    }
}

Now a unit test can hand the Facade a PaymentService stub that returns false and assert you get back "FAILED: payment declined" without touching a real gateway.

5A real-world example#

You already use Facades every day. The order flow above is the textbook case, but the pattern hides inside tools you ship with:

• SLF4J and logging. Your app calls logger.info(...). The name says it: SLF4J is the Simple Logging Facade for Java. Behind one call, a subsystem picks the backend (Logback, java.util.logging), formats the message, and routes it. Swap Logback for Log4j2 and not one logger.info call changes.
• JDBC-style data access. A UserRepository with findById and save hides connection pooling, prepared statements, result-set mapping, and transactions. The caller just wants a user, not 5 steps of boilerplate.
• Compiler and build tools. One build command kicks off parsing, dependency resolution, compilation, and packaging in order. You are not calling each phase yourself.
• Payment integrations. A Payments.charge(...) wrapper hides Stripe, retries, idempotency keys, and currency conversion. The rest of the app does not know Stripe exists, so adding a second gateway touches one class.

In an LLD setting, the tell is a "do the whole thing" operation. Any time your problem fans a single verb (place order, start a ride, book a movie seat, publish a post) out into several subsystems, a Facade is the natural coordinator.

6When to use it, and when not to#

A Facade should feel like it could be deleted and the subsystem would still work. It is a convenience layer, not the brain.

7Common mistakes#

These are the ones that come up in interviews, and the first two fail candidates.

• Turning it into a God object. The most common failure. The Facade starts thin, then someone adds validation, then pricing math, then a cache, and now 800 lines of unrelated logic live in one class. That breaks Single Responsibility hard. It delegates; it does not compute.
• Forcing all access through it. A Facade simplifies the common path, it does not forbid the uncommon one. If an advanced caller needs InventoryService directly, let them. A sealed-off subsystem is a liability.
• Confusing it with Adapter. Adapter changes an interface to match what a client expects (a square peg into a round hole). Facade simplifies interfaces that already work. Adapter is about compatibility, Facade about convenience. Giveaway: Adapter usually wraps exactly one class, Facade fronts several.
• Confusing it with Mediator. Mediator sits between peers so they can talk without direct links. Facade sits in front of a subsystem so an outsider can talk to it easily. Mediator faces inward, Facade faces outward. Also: subsystem classes know about the Mediator, but they never know about the Facade.
• Leaking subsystem types in the signature. If placeOrder returns an InventoryReservation full of internal fields, you just leaked the subsystem to the client, and now they depend on it anyway. Return simple results or your own clean DTO.

8Where it shows up in interviews#

Facade rarely headlines, because it is Easy. It plays a supporting role inside a bigger design, and knowing to name it scores points.

• Expect it when you design an order service, a ride-booking flow, a notification system, or a payment module.
• You will sketch several services, then the interviewer asks "how does a caller actually trigger all of this?"
• The answer: "I put a Facade in front so the controller calls one method." That shows you think about API surface and coupling.

Next, I would study the Adapter pattern (its most-confused cousin) and the Mediator pattern, then try applying Facade inside a full "design an order management system" LLD problem.