Facade Pattern: A Simple Entry Point to a Complex Subsystem

Facade Pattern

Intent: provide a unified, higher-level interface to a set of interfaces in a subsystem, making the subsystem easier to use for the common case — without hiding it, and without preventing callers from reaching in and using the subsystem directly when they need to.

Every backend system accumulates subsystems that are individually reasonable but collectively exhausting to orchestrate correctly: order placement touches inventory, pricing, payment, tax, and notifications. Video encoding touches demuxing, codec selection, format conversion, and thumbnailing. Facade is the pattern for giving most callers a front door, while leaving the side doors open for the few callers who need them.

1. The problem: correct orchestration requires knowing five classes

Consider placing an order in an e-commerce backend. The subsystem is made of independently-evolving, correctly-scoped classes:

class InventoryService {
    boolean reserve(String sku, int qty) { /* ... */ return true; }
    void release(String sku, int qty) { /* ... */ }
}
 
class PricingEngine {
    Money calculateTotal(Cart cart, String customerId) { /* applies discounts, tax */ return Money.ZERO; }
}
 
class PaymentGateway {
    PaymentResult charge(String customerId, Money amount) { /* ... */ return PaymentResult.success("txn1"); }
    void refund(String transactionId) { /* ... */ }
}
 
class ShippingScheduler {
    ShipmentId schedule(Cart cart, Address address) { /* ... */ return new ShipmentId("s1"); }
}
 
class NotificationService {
    void sendOrderConfirmation(String customerId, ShipmentId shipmentId) { /* ... */ }
}

Each class is well-designed on its own — small, single-purpose, testable. The problem is correctly sequencing them, including the failure paths.

VIOLATION: every caller re-implements the orchestration (and gets it wrong differently each time)

// VIOLATION: this orchestration logic gets copy-pasted into every controller
// that needs to place an order — web checkout, mobile checkout, admin re-order,
// each with slightly different (and slightly buggy) error handling.
class WebCheckoutController {
    private final InventoryService inventory = new InventoryService();
    private final PricingEngine pricing = new PricingEngine();
    private final PaymentGateway payments = new PaymentGateway();
    private final ShippingScheduler shipping = new ShippingScheduler();
    private final NotificationService notifications = new NotificationService();
 
    OrderResult placeOrder(Cart cart, String customerId, Address address) {
        for (CartItem item : cart.getItems()) {
            if (!inventory.reserve(item.getSku(), item.getQty())) {
                throw new RuntimeException("out of stock"); // forgot to release earlier reservations!
            }
        }
        Money total = pricing.calculateTotal(cart, customerId);
        PaymentResult payment = payments.charge(customerId, total);
        if (!payment.isSuccessful()) {
            // forgot to release inventory reservations here too
            throw new RuntimeException("payment failed");
        }
        ShipmentId shipmentId = shipping.schedule(cart, address);
        notifications.sendOrderConfirmation(customerId, shipmentId);
        return new OrderResult(shipmentId, payment.getTransactionId());
    }
}

Every caller must know: the exact call order, that a failed reservation mid-loop needs the earlier ones released, that a failed payment needs inventory released too, and that notification comes last. Miss one compensating step in any call site and you leak reserved inventory or silently skip a confirmation email — bugs that only show up in production, under contention.

2. The fix: one Facade owns the orchestration once

// FIXED: the correct sequencing — including compensation on failure — lives in ONE place.
class OrderFacade {
    private final InventoryService inventory;
    private final PricingEngine pricing;
    private final PaymentGateway payments;
    private final ShippingScheduler shipping;
    private final NotificationService notifications;
 
    OrderFacade(InventoryService inventory, PricingEngine pricing, PaymentGateway payments,
                ShippingScheduler shipping, NotificationService notifications) {
        this.inventory = inventory;
        this.pricing = pricing;
        this.payments = payments;
        this.shipping = shipping;
        this.notifications = notifications;
    }
 
    OrderResult placeOrder(Cart cart, String customerId, Address address) {
        List<CartItem> reserved = new ArrayList<>();
        try {
            for (CartItem item : cart.getItems()) {
                if (!inventory.reserve(item.getSku(), item.getQty())) {
                    throw new OutOfStockException(item.getSku());
                }
                reserved.add(item);
            }
 
            Money total = pricing.calculateTotal(cart, customerId);
            PaymentResult payment = payments.charge(customerId, total);
            if (!payment.isSuccessful()) {
                throw new PaymentFailedException(payment.getMessage());
            }
 
            ShipmentId shipmentId = shipping.schedule(cart, address);
            notifications.sendOrderConfirmation(customerId, shipmentId);
            return new OrderResult(shipmentId, payment.getTransactionId());
 
        } catch (RuntimeException ex) {
            reserved.forEach(item -> inventory.release(item.getSku(), item.getQty())); // one compensation path
            throw ex;
        }
    }
}
 
// Every caller now gets the correct behavior for free
class WebCheckoutController {
    private final OrderFacade orderFacade; // injected
 
    WebCheckoutController(OrderFacade orderFacade) {
        this.orderFacade = orderFacade;
    }
 
    OrderResult checkout(Cart cart, String customerId, Address address) {
        return orderFacade.placeOrder(cart, customerId, address);
    }
}

3. When to use vs. when it's overkill

4. Facade vs. Adapter

Both wrap other code, but for opposite reasons. See Adapter Pattern for the full write-up; the short version:

5. Facade vs. Mediator

This is the pairing people mix up more often, because both patterns "coordinate multiple objects." The difference is direction of dependency and number of participants coordinated:

6. When Facade becomes an anti-pattern

Facade earns its keep by staying thin — pure orchestration, no new business rules. It stops being helpful and starts being a liability in two common ways:

Leaky abstraction. If callers still need to reach past the facade to get subsystem-specific error details, configuration, or partial results, the facade has failed at its one job — hiding complexity, not capability. A facade whose exceptions are generic RuntimeException wrappers that erase which subsystem failed forces callers back into the subsystem anyway, just with worse types.

// ANTI-PATTERN: facade swallows the useful information
class LeakyOrderFacade {
    OrderResult placeOrder(Cart cart, String customerId, Address address) {
        try {
            // ... orchestration ...
            return null;
        } catch (Exception e) {
            throw new RuntimeException("something went wrong"); // which subsystem? unrecoverable info loss
        }
    }
}

God facade. A facade that accumulates every operation any caller has ever needed — OrderFacade growing methods for refunds, inventory audits, pricing simulations, and customer support overrides — has become a second god class sitting in front of the first five. This is the SRP violation reappearing one layer up: the facade itself now has many reasons to change. If a facade's method count is growing unboundedly, split it into use-case-specific facades (OrderPlacementFacade, OrderRefundFacade) rather than one that does everything.

7. Real-world facades

• javax.faces.context.FacesContext in JSF — a single access point over request, response, session, and application state.
• Spring's JdbcTemplate — a facade over the verbose, exception-prone raw JDBC API (Connection, Statement, ResultSet, manual resource closing, checked SQLException translation).
• SLF4J's Logger — a facade over whatever logging backend (Logback, Log4j2, java.util.logging) is actually configured; application code calls one simple API regardless of backend.
• AWS SDK's high-level S3TransferManager — a facade over the low-level multipart upload/download subsystem, handling chunking, retries, and parallelism behind one upload() call.
• Payment orchestration services in most fintech backends — exactly the OrderFacade shape above, coordinating fraud checks, ledger entries, and the actual gateway call behind one processPayment() entry point.

Interview Questions

• What problem does Facade solve, and why is it wrong to think of it as "hiding" the subsystem?
• Walk through the checkout example. What specifically goes wrong if five different controllers each re-implement the order-placement orchestration?
• What is a "leaky" facade, and what's the concrete signal that a facade has become one?
• Compare Facade and Mediator. Both coordinate multiple classes — what's the actual structural difference?
• Compare Facade and Adapter. Could a single class ever be both? Explain with an example.
• When does a facade become a "god object," and how do you split it correctly?
• Why should subsystem classes behind a facade generally remain public rather than being made package-private?
• Give a real Java standard library or Spring example of a facade, and identify which classes make up the subsystem it simplifies.