Facade pattern in LLD - Scalability & System Analysis

Scalability Analysis - Facade pattern

Growth Table: Facade Pattern

Users / Scale	System Complexity	Subsystem Calls	Performance Impact	Maintenance Effort
100 users	Simple facade calls few subsystems	Low number of calls, minimal overhead	Negligible latency	Easy to maintain
10,000 users	More concurrent facade requests	Increased subsystem calls, some queuing	Moderate latency possible	Need monitoring for bottlenecks
1,000,000 users	High concurrency, many facade instances	Subsystems may become overloaded	Latency increases, possible timeouts	Complex coordination and scaling needed
100,000,000 users	Massive scale, distributed facades	Subsystems must be highly scalable	Latency critical, failures impact facade	Requires automated scaling and fault tolerance

First Bottleneck

The first bottleneck is usually the subsystems behind the facade. As user requests grow, the facade itself is lightweight but the underlying subsystems it calls can become overloaded. This causes increased latency and failures that propagate through the facade.

Scaling Solutions

• Horizontal scaling: Add more instances of subsystems and facade servers behind load balancers.
• Caching: Cache frequent responses at the facade to reduce subsystem calls.
• Asynchronous calls: Use async messaging to decouple facade from slow subsystems.
• Sharding: Partition data and subsystem responsibilities to reduce load per instance.
• Rate limiting: Protect subsystems by limiting facade request rates.
• Monitoring and circuit breakers: Detect failures early and prevent cascading issues.

Back-of-Envelope Cost Analysis

• At 1M users, assuming 1 request per second per user, facade handles ~1M RPS.
• Each facade request calls 3 subsystems on average -> 3M subsystem calls per second.
• Subsystem servers handle ~5,000 RPS each -> need ~600 servers total.
• Network bandwidth depends on payload size; assume 10KB per request -> 10GB/s total bandwidth.
• Caching can reduce subsystem calls by 50% or more, cutting server needs and bandwidth.

Interview Tip

When discussing facade pattern scalability, start by explaining the facade role as a simple interface. Then identify that subsystems are the real bottleneck as load grows. Discuss how horizontal scaling, caching, and async communication help. Always connect solutions to the bottleneck you identified.

Self Check

Your database handles 1000 QPS. Traffic grows 10x. What do you do first?

Answer: Add read replicas and caching layers to reduce load on the main database before scaling application servers.

Key Result

Facade pattern itself scales well, but underlying subsystems become bottlenecks first; scaling requires subsystem horizontal scaling, caching, and async decoupling.

Practice

1. What is the main purpose of the Facade pattern in system design?

easy

A. To make the system slower by adding extra layers

B. To increase the number of classes in a system

C. To provide a simple interface to a complex system

D. To replace all subsystem classes with one class

Solution

1. Step 1: Understand the Facade pattern role

   The Facade pattern is designed to simplify interactions by providing a single interface to a complex system.

2. Step 2: Compare options with the pattern's purpose

   To provide a simple interface to a complex system correctly states the purpose. Options A, B, and C describe incorrect or harmful effects.

3. Final Answer:

   To provide a simple interface to a complex system -> Option C

4. Quick Check:

   Facade pattern = Simple interface [OK]

Hint: Facade means simple front for complex system [OK]

Common Mistakes:

• Thinking Facade replaces all classes
• Believing Facade adds complexity
• Confusing Facade with Singleton pattern

2. Which of the following is the correct way to define a Facade class method in a typical object-oriented language?

easy

A. private void complexOperation() { subsystem1.action(); }

B. public int complexOperation() { subsystem1.action(); subsystem2.action(); return 0; }

C. void complexOperation() { return subsystem1.action(); }

D. public void complexOperation() { subsystem1.action(); subsystem2.action(); }

Solution

1. Step 1: Identify Facade method visibility and calls

   Facade methods are usually public to expose simplified operations and call multiple subsystems internally.

2. Step 2: Check each option's correctness

   public void complexOperation() { subsystem1.action(); subsystem2.action(); } is public and calls multiple subsystems, matching Facade pattern. private void complexOperation() { subsystem1.action(); } is private, so not accessible. void complexOperation() { return subsystem1.action(); } returns a value but calls only one subsystem. public int complexOperation() { subsystem1.action(); subsystem2.action(); return 0; } returns int unnecessarily.

3. Final Answer:

   public void complexOperation() { subsystem1.action(); subsystem2.action(); } -> Option D

4. Quick Check:

   Facade method = public + multiple calls [OK]

Hint: Facade methods are public and call multiple subsystems [OK]

Common Mistakes:

• Making Facade methods private
• Returning values unnecessarily
• Calling only one subsystem inside Facade

3. Given this Facade code snippet, what will be the output?

class SubsystemA {
  void operationA() { print('A'); }
}
class SubsystemB {
  void operationB() { print('B'); }
}
class Facade {
  SubsystemA a = SubsystemA();
  SubsystemB b = SubsystemB();
  void doWork() {
    a.operationA();
    b.operationB();
  }
}
void main() {
  Facade f = Facade();
  f.doWork();
}

medium

A. BA

B. AB

C. A B

D. No output

Solution

1. Step 1: Trace Facade's doWork method calls

   doWork calls operationA() then operationB(), which print 'A' and 'B' respectively.

2. Step 2: Determine output sequence

   Since operationA prints 'A' first, then operationB prints 'B', output is 'AB' without spaces.

3. Final Answer:

   AB -> Option B

4. Quick Check:

   Facade calls order = AB [OK]

Hint: Follow method calls in order to find output [OK]

Common Mistakes:

• Assuming output is 'BA' reversing calls
• Expecting spaces between prints
• Thinking no output due to missing return

4. Identify the error in this Facade implementation:

class Subsystem {
  void action() { print('Action'); }
}
class Facade {
  Subsystem subsystem;
  void doTask() {
    subsystem.action();
  }
}
void main() {
  Facade f = Facade();
  f.doTask();
}

medium

A. Subsystem object is not initialized before use

B. Facade class should not call subsystem methods

C. doTask method should return a value

D. Subsystem class should be abstract

Solution

1. Step 1: Check subsystem object usage in Facade

   The Facade has a subsystem field but never initializes it before calling action(), causing a null reference error.

2. Step 2: Validate other options

   Facade class should not call subsystem methods is wrong because Facade should call subsystem methods. doTask method should return a value is not required. Subsystem class should be abstract is unnecessary.

3. Final Answer:

   Subsystem object is not initialized before use -> Option A

4. Quick Check:

   Uninitialized object = runtime error [OK]

Hint: Always initialize objects before calling methods [OK]

Common Mistakes:

• Ignoring null object initialization
• Thinking Facade should not call subsystems
• Expecting return values unnecessarily

5. You are designing a home automation system with many devices: lights, thermostat, security cameras, and music system. How would applying the Facade pattern help in this scenario?

hard

A. Create a single HomeAutomationFacade class that provides simple methods like turnOnAll() and setTemperature() to control all devices

B. Replace all device classes with one large class containing all device logic

C. Make each device class inherit from a common Facade superclass

D. Use Facade pattern to split each device into smaller classes

Solution

1. Step 1: Understand Facade's role in simplifying complex systems

   Facade groups multiple subsystem calls into simple methods, hiding complexity from users.

2. Step 2: Apply this to home automation

   Create a single HomeAutomationFacade class that provides simple methods like turnOnAll() and setTemperature() to control all devices correctly describes creating a Facade class with simple methods controlling multiple devices. Options A, B, and D misunderstand Facade's purpose.

3. Final Answer:

   Create a single HomeAutomationFacade class that provides simple methods like turnOnAll() and setTemperature() to control all devices -> Option A

4. Quick Check:

   Facade = simple interface for complex devices [OK]

Hint: Facade groups complex calls into simple methods [OK]

Common Mistakes:

• Merging all logic into one big class
• Confusing Facade with inheritance
• Splitting devices further instead of simplifying