← System Design
🎭
System Design

Facade

One simple API in front of a messy subsystem. The whole concept of an "API gateway" is the Facade pattern at scale.

TL;DR

A Facade is a single, simplified interface that hides a tangled subsystem behind it. The client calls `OrderService.placeOrder(...)`; behind that one call the facade orchestrates inventory, payment, fulfillment, notifications, and analytics. The complexity doesn't go away — but the client never has to see it. The whole concept of an API gateway is the Facade pattern at scale.

When to use

Whenever you have a subsystem with many moving parts that callers shouldn't (or can't) understand. Use it to onboard new services, simplify cross-team APIs, or wall off legacy code so the rest of the system doesn't depend on its internals.

Try it

A canonical example

You’re building checkout. The “place order” operation actually involves:

  1. Reserving inventory in the warehouse service.
  2. Authorizing the payment via the payment gateway.
  3. Creating the order record in the database.
  4. Scheduling fulfillment in the logistics service.
  5. Firing the OrderPlaced event for downstream consumers.
  6. Sending a confirmation email/SMS.

You don’t want every caller (mobile app, web app, partner API, CSV import) to coordinate all six. You expose a single facade method:

class OrderFacade {
  async placeOrder(cart: Cart, payment: PaymentMethod, customer: Customer): Promise<OrderId> {
    const reservation = await this.inventory.reserve(cart);
    try {
      const charge = await this.payments.authorize(payment, cart.total);
      const order = await this.orders.create(cart, charge.id, customer);
      await this.logistics.schedule(order);
      await this.eventBus.publish(new OrderPlaced(order));
      await this.notifier.send(customer, `Order ${order.id} confirmed`);
      return order.id;
    } catch (err) {
      await this.inventory.release(reservation);
      throw err;
    }
  }
}

Facade vs Adapter

The API gateway is just a Facade at scale

Trade-offs

Pros: Massive reduction in caller complexity; safe place for cross-cutting concerns (auth, retries, tracing); enables refactoring of internals.

In real systems

  • API gateways (Kong, Apigee, AWS API Gateway, Azure API Management) — facades for whole microservice fleets.
  • GraphQL — a facade where the client describes the shape; one query replaces many REST calls.
  • SDKs — every cloud SDK (AWS.S3, azure-storage-blob) is a facade over the raw HTTP API.
  • Service meshes — sidecars facade away retries, mTLS, telemetry — the app code stays simple.
📺 Video

A YouTube walkthrough — coming once the deep-dive video is published.

🧪 Simulator

An interactive simulator for this concept is on the way — tweak the knobs, watch behaviour change in real time.

💻 Code

A 30-line build challenge with starter code, hints, and a reference implementation.

🎯 Common interview questions
Q1. How is a Facade different from an Adapter?

Adapter changes the *shape* of an interface so two incompatible types can talk (e.g. wrapping a legacy SOAP service in a REST shim). Facade *simplifies* a complex interface — it usually combines multiple subsystem calls into one logical operation. Adapter is one-to-one translation; Facade is many-to-one composition.

Q2. Isn't an API gateway just a Facade?

Yes — that's exactly what it is. Microservices behind a gateway each expose narrow APIs; the gateway combines them into product-shaped endpoints (`/checkout` calls inventory + pricing + payment + fulfillment). The gateway is also a great place to add cross-cutting concerns — auth, rate limits, observability — without polluting the underlying services.

Q3. What's the risk of a Facade?

The facade can become a god-object — every new feature gets stuffed into it because that's where the orchestration already lives. Counter this by enforcing the rule that the facade only *coordinates*; business logic belongs in the underlying services. When a facade method gets longer than ~20 lines, it's usually doing too much.

Q4. How does this connect to the BFF (Backend-for-Frontend) pattern?

BFF is a Facade specialized per client — one for web, one for mobile, one for the partner API. Each BFF picks exactly the data and shape that client needs, instead of every client consuming a one-size-fits-all gateway. It's the Interface Segregation principle applied to gateways.

Q5. Where else have I seen this pattern without realizing?

jQuery (`$('#x').hide()` hides decades of cross-browser DOM hacks behind one method). React's `<input>` (one component reconciles uncontrolled DOM input behavior across browsers). The `fetch()` API (one call hides DNS, TCP, TLS, HTTP). Every clean SDK is a facade over messy network protocols.

↗ Related concepts

Comments 0

Discuss this page. Markdown supported. Be kind.

Loading…
Loading comments…