Chain of Responsibility pattern in LLD - System Design Exercise

Design: Chain of Responsibility Pattern Implementation

Design focuses on the pattern implementation and request flow. Out of scope are UI details, persistence, and distributed system concerns.

Functional Requirements

FR1: Design a system where multiple handlers can process a request in a sequence.

FR2: Each handler decides either to process the request or pass it to the next handler.

FR3: The system should allow dynamic addition or removal of handlers.

FR4: Requests should be processed by the first capable handler only.

FR5: Support different types of requests with different handlers.

Non-Functional Requirements

NFR1: The system should handle up to 1000 requests per second.

NFR2: Latency for processing each request should be under 100ms.

NFR3: The design should be extensible to add new handlers without modifying existing code.

NFR4: Ensure thread safety if handlers are used in concurrent environments.

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

Key Components

Handler interface or abstract class

Concrete handler implementations

Request object abstraction

Chain manager or builder to link handlers

Client that sends requests

Design Patterns

Chain of Responsibility pattern

Command pattern for encapsulating requests

Decorator pattern if handlers add behavior

Observer pattern if handlers notify others

Reference Architecture

Client
  |
  v
[Chain Manager] --> [Handler 1] --> [Handler 2] --> [Handler 3] --> ... --> [Handler N]
Each handler decides to process or pass the request to the next handler.

Components

Handler Interface

Abstract class or interface in chosen language

Defines method to process request and link to next handler

Concrete Handlers

Classes implementing Handler interface

Implement specific logic to handle certain requests or pass along

Request Object

Class or data structure

Encapsulates request data and type

Chain Manager

Class or builder pattern

Creates and links handlers into a chain

Client

Any caller code

Sends requests to the chain for processing

Request Flow

1. Client creates a request object.

2. Client sends the request to the Chain Manager.

3. Chain Manager passes the request to the first handler in the chain.

4. Handler checks if it can process the request.

5. If yes, handler processes and returns response.

6. If no, handler passes request to the next handler.

7. This continues until a handler processes the request or chain ends.

8. If no handler processes, return a default response or error.

Database Schema

Not applicable as this pattern focuses on in-memory request handling and does not require persistent storage.

Scaling Discussion

Bottlenecks

Long chains can increase latency as requests pass through many handlers.

Single-threaded chains may limit throughput under high load.

Adding/removing handlers dynamically may cause inconsistent chain states.

Handlers with heavy processing can slow down the chain.

Solutions

Limit chain length or group handlers by request type to reduce unnecessary passes.

Use concurrent or asynchronous processing where handlers can run in parallel if independent.

Implement thread-safe chain management with locks or atomic operations.

Optimize handler logic or offload heavy processing to background jobs.

Interview Tips

Time: Spend 10 minutes understanding requirements and clarifying questions, 20 minutes designing the pattern and explaining components, 10 minutes discussing scaling and trade-offs, 5 minutes for questions.

Explain the purpose of the Chain of Responsibility pattern clearly.

Describe how handlers are linked and how requests flow through the chain.

Discuss extensibility and how new handlers can be added without changing existing code.

Mention thread safety and concurrency considerations.

Talk about potential bottlenecks and how to scale the design.