Facade pattern in LLD - System Design Exercise

Design: Facade Pattern Design

Design a software component that acts as a facade to multiple complex subsystems, simplifying client interaction. Out of scope: detailed implementation of subsystems.

Functional Requirements

FR1: Provide a simplified interface to a complex subsystem

FR2: Hide the complexity of multiple underlying components from the client

FR3: Allow clients to interact with the system easily without knowing internal details

FR4: Support extensibility to add or modify subsystems without affecting clients

Non-Functional Requirements

NFR1: The facade should not add significant performance overhead

NFR2: The design should maintain loose coupling between clients and subsystems

NFR3: The system should be scalable to add more subsystems in the future

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

Key Components

Facade component providing simplified interface

Multiple subsystem components with complex interfaces

Client component interacting only with the facade

Optional adapters or wrappers for subsystems

Design Patterns

Facade pattern for interface simplification

Adapter pattern if subsystem interfaces differ

Proxy pattern for controlling access

Observer pattern if subsystems need to notify facade

Reference Architecture

Client
  |
  v
Facade
 / | \
Subsystem1 Subsystem2 Subsystem3

Components

Facade

Any OOP language (e.g., Java, Python, C#)

Provide a simple unified interface to multiple complex subsystems

Subsystem1

Any OOP language

Handles specific complex operations hidden behind facade

Subsystem2

Any OOP language

Another complex subsystem with its own interface

Subsystem3

Any OOP language

Additional subsystem encapsulated by facade

Client

Any OOP language

Uses facade to interact with subsystems without complexity

Request Flow

1. Client calls a method on the Facade interface

2. Facade translates the call into one or more calls to subsystems

3. Subsystems perform their complex operations internally

4. Facade collects results or handles errors from subsystems

5. Facade returns a simplified response to the Client

Database Schema

Not applicable as this pattern focuses on software component interaction rather than data storage.

Scaling Discussion

Bottlenecks

Facade becoming a monolithic component if too many subsystems are added

Performance overhead if facade calls many subsystems sequentially

Difficulty maintaining facade if subsystems change frequently

Solutions

Modularize facade internally to delegate to smaller facades or handlers

Use asynchronous calls or parallel processing to improve performance

Apply adapter pattern to isolate facade from subsystem changes

Interview Tips

Time: Spend 10 minutes explaining the problem and requirements, 20 minutes designing the facade and subsystems interaction, 10 minutes discussing scaling and trade-offs, and 5 minutes answering questions.

Explain how facade simplifies client interaction by hiding subsystem complexity

Discuss how loose coupling is maintained between facade and subsystems

Mention extensibility to add or modify subsystems without affecting clients

Highlight potential bottlenecks and how to mitigate them

Show understanding of related design patterns like Adapter and Proxy