Single Responsibility Principle in LLD - System Design Exercise

Design: Single Responsibility Principle Application

Focus on designing a system architecture that follows the Single Responsibility Principle (SRP). Do not cover other SOLID principles or detailed implementation code. Exclude performance optimization and deployment concerns.

Functional Requirements

FR1: Design a system where each module or class has only one reason to change.

FR2: Ensure that each component handles a single responsibility or functionality.

FR3: Allow easy maintenance and scalability by minimizing the impact of changes.

FR4: Support clear separation of concerns within the system.

Non-Functional Requirements

NFR1: The system should be modular and easy to understand.

NFR2: Changes in one responsibility should not affect others.

NFR3: The design should support future extensions without modifying existing modules.

NFR4: The system should be simple enough for beginners to understand.

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

Key Components

Modules or classes representing single responsibilities

Interfaces or abstractions to separate concerns

Communication between modules with minimal coupling

Error handling and logging separated from business logic

Design Patterns

Single Responsibility Principle (SRP)

Separation of Concerns

Modular Design

Interface Segregation

Reference Architecture

  +-------------------+      +-------------------+      +-------------------+
  |   User Interface  | ---> |  Business Logic   | ---> |   Data Access     |
  |  (Handles input)  |      | (Processes data)  |      | (Reads/Writes DB) |
  +-------------------+      +-------------------+      +-------------------+
          |                         |                          |
          |                         |                          |
          +-------------------------+--------------------------+
                            Clear separation of responsibilities

Components

User Interface Module

Any UI framework or plain code

Handles user input and output only, no business logic

Business Logic Module

Any programming language classes or modules

Processes data and applies business rules, no UI or data storage code

Data Access Module

Database connectors or ORM

Handles all database interactions, no business logic or UI code

Request Flow

1. User interacts with the User Interface module.

2. User Interface sends input data to the Business Logic module.

3. Business Logic processes data and applies rules.

4. Business Logic requests data storage or retrieval from Data Access module.

5. Data Access module interacts with the database and returns results.

6. Business Logic sends processed results back to User Interface.

7. User Interface displays results to the user.

Database Schema

Not applicable as SRP focuses on code/module design rather than database design.

Scaling Discussion

Bottlenecks

Modules becoming too large and handling multiple responsibilities.

Tight coupling between modules making changes risky.

Difficulty in testing due to mixed responsibilities.

Slow development and maintenance due to unclear module boundaries.

Solutions

Refactor large modules into smaller ones each with a single responsibility.

Use interfaces and abstractions to reduce coupling.

Write unit tests for each module independently.

Regularly review and enforce SRP during code reviews.

Interview Tips

Time: Spend 10 minutes explaining SRP concept and importance, 20 minutes designing a simple system applying SRP, 15 minutes discussing scaling and maintenance benefits.

Explain SRP as one reason to change per module/class.

Show clear separation of concerns in your design.

Discuss how SRP improves maintainability and scalability.

Mention how SRP helps in testing and reduces bugs.

Highlight the importance of modular design and loose coupling.