Interface Segregation Principle in LLD - System Design Exercise

Design: Interface Segregation Principle Application

Focus on designing interfaces and their segregation in a modular system. Implementation details of business logic are out of scope.

Functional Requirements

FR1: Design interfaces that are client-specific and do not force clients to depend on methods they do not use.

FR2: Ensure that the system supports multiple types of clients with different needs without unnecessary dependencies.

FR3: Allow easy extension and maintenance by minimizing the impact of changes on unrelated clients.

Non-Functional Requirements

NFR1: The system should handle up to 1000 concurrent clients with different interface needs.

NFR2: API response latency should be under 100ms for interface method calls.

NFR3: Maintain high code maintainability and low coupling between components.

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

Key Components

Client-specific interfaces

Implementation classes that implement multiple small interfaces

Interface adapters or facades if needed

Dependency injection to bind clients to specific interfaces

Design Patterns

Interface Segregation Principle (ISP)

Adapter Pattern

Facade Pattern

Dependency Injection

Reference Architecture

  +----------------+       +----------------+       +----------------+
  | Client Type A  |       | Client Type B  |       | Client Type C  |
  +-------+--------+       +-------+--------+       +-------+--------+
          |                        |                        |
          |                        |                        |
  +-------v--------+       +-------v--------+       +-------v--------+
  | Interface A    |       | Interface B    |       | Interface C    |
  +-------+--------+       +-------+--------+       +-------+--------+
          |                        |                        |
          +-----------+------------+------------+-----------+
                      |                         |
              +-------v--------+        +-------v--------+
              | Implementation |        | Implementation |
              | Class 1        |        | Class 2        |
              +----------------+        +----------------+

Components

Client Type A Interface

Interface in chosen language

Defines only the methods needed by Client Type A

Client Type B Interface

Interface in chosen language

Defines only the methods needed by Client Type B

Client Type C Interface

Interface in chosen language

Defines only the methods needed by Client Type C

Implementation Classes

Classes implementing multiple small interfaces

Provide concrete behavior for segregated interfaces

Dependency Injection Container

DI framework or manual injection

Bind clients to the correct interface implementations

Request Flow

1. Client Type A requests service via Interface A.

2. Request is routed to Implementation Class that implements Interface A.

3. Implementation Class executes only methods defined in Interface A.

4. Client Type B uses Interface B similarly, without seeing Interface A methods.

5. This segregation prevents clients from depending on unused methods.

6. New client types can be added by defining new interfaces without changing existing ones.

Database Schema

Not applicable as this design focuses on interface segregation and modular code structure rather than data storage.

Scaling Discussion

Bottlenecks

Large monolithic interfaces causing clients to depend on unused methods.

Implementation classes becoming too large by implementing many interfaces.

Difficulty in maintaining and extending interfaces as client types grow.

Solutions

Split large interfaces into smaller, client-specific interfaces following ISP.

Use composition to delegate responsibilities to smaller classes.

Apply dependency injection to manage interface implementations cleanly.

Regularly review and refactor interfaces as new client requirements emerge.

Interview Tips

Time: Spend 10 minutes understanding client needs and interface requirements, 15 minutes designing segregated interfaces and implementation classes, 10 minutes discussing scaling and maintenance, and 10 minutes answering questions.

Explain why large interfaces cause problems for clients.

Describe how segregating interfaces improves modularity and maintainability.

Show how different clients get only the methods they need.

Discuss how this design supports future extension without breaking existing clients.

Mention patterns like Adapter and Dependency Injection that complement ISP.