Separation of concerns in LLD - System Design Exercise

Design: Separation of Concerns in Software Design

Focus on designing a software system architecture that applies separation of concerns principles. Out of scope are specific programming language implementations or UI design details.

Functional Requirements

FR1: Divide the system into distinct sections, each handling a specific responsibility

FR2: Ensure that changes in one section have minimal impact on others

FR3: Support easy maintenance and scalability

FR4: Allow independent development and testing of each section

Non-Functional Requirements

NFR1: Keep clear boundaries between concerns to avoid overlap

NFR2: Design for modularity and reusability

NFR3: Maintain low coupling and high cohesion

NFR4: Support integration of different modules with well-defined interfaces

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

Key Components

Presentation layer (UI or API)

Business logic layer

Data access layer

Service or integration layer

Common utilities or helpers

Design Patterns

Layered architecture

Model-View-Controller (MVC)

Microservices

Event-driven architecture

Dependency injection

Reference Architecture

  +-------------------+       +-------------------+       +-------------------+
  |   Presentation    | <---> |   Business Logic  | <---> |   Data Access     |
  |    Layer (UI)     |       |      Layer        |       |      Layer        |
  +-------------------+       +-------------------+       +-------------------+
           |                          |                           |
           v                          v                           v
  +-------------------+       +-------------------+       +-------------------+
  |  Service Layer /   |       |  Utilities Layer  |       | External Systems  |
  | Integration Layer  |       |                   |       | (DB, APIs, etc.)  |
  +-------------------+       +-------------------+       +-------------------+

Components

Presentation Layer

Any UI framework or API gateway

Handles user interaction and input/output formatting

Business Logic Layer

Application server or service code

Processes core rules and workflows of the system

Data Access Layer

Database connectors, ORM tools

Manages data storage and retrieval

Service Layer / Integration Layer

REST/gRPC services, message queues

Coordinates communication between modules and external systems

Utilities Layer

Common libraries or helper modules

Provides shared functions like logging, validation, error handling

Request Flow

1. User sends a request to the Presentation Layer

2. Presentation Layer validates input and forwards to Business Logic Layer

3. Business Logic Layer applies rules and calls Data Access Layer for data

4. Data Access Layer queries or updates the database

5. Results flow back through Business Logic Layer to Presentation Layer

6. Presentation Layer formats response and sends back to user

7. Service Layer manages communication if external systems are involved

8. Utilities Layer supports all layers with common functions

Database Schema

Entities depend on system domain but are accessed only via Data Access Layer. Relationships are managed by Business Logic Layer to keep data integrity. Example: User, Order, Product entities with appropriate foreign keys.

Scaling Discussion

Bottlenecks

Tight coupling between layers causing ripple effects on changes

Monolithic design limiting independent scaling of components

Single database becoming a performance bottleneck

Complex inter-module communication slowing down response times

Solutions

Enforce strict interfaces and contracts between layers to reduce coupling

Adopt microservices to separate concerns into independently deployable units

Use database sharding, replication, or caching to improve data layer scalability

Implement asynchronous communication and message queues to decouple modules

Interview Tips

Time: Spend 10 minutes understanding and clarifying requirements, 20 minutes designing the layered architecture with separation of concerns, and 15 minutes discussing scaling and trade-offs.

Explain the importance of dividing responsibilities clearly

Describe how each layer has a focused role and communicates via interfaces

Discuss how separation of concerns improves maintainability and testing

Highlight how the design supports future changes and scaling

Mention common patterns like MVC or microservices as examples

Practice

1. What is the main purpose of separation of concerns in system design?

easy

A. To divide a system into parts that each handle a specific job

B. To combine all system functions into one module

C. To make the system run faster by using fewer parts

D. To remove all interfaces between system components

Solution

1. Step 1: Understand the concept of separation of concerns

   It means dividing a system into parts where each part has a clear, specific responsibility.

2. Step 2: Compare options with the concept

   Only To divide a system into parts that each handle a specific job describes dividing the system into parts with specific jobs, matching the concept.

3. Final Answer:

   To divide a system into parts that each handle a specific job -> Option A

4. Quick Check:

   Separation of concerns = divide system parts [OK]

Hint: Think: separate jobs make systems simpler [OK]

Common Mistakes:

• Confusing separation with combining functions
• Thinking it speeds up system by reducing parts
• Ignoring the role of interfaces

2. Which of the following is the correct way to apply separation of concerns in code structure?

easy

A. Separating UI code, business logic, and data access into different modules

B. Writing all code in one large file for easy access

C. Mixing UI logic and data processing in the same function

D. Ignoring interfaces between different parts

Solution

1. Step 1: Identify proper separation in code

   Separation of concerns means keeping UI, logic, and data handling separate.

2. Step 2: Match options to this principle

   Separating UI code, business logic, and data access into different modules correctly separates these concerns into different modules.

3. Final Answer:

   Separating UI code, business logic, and data access into different modules -> Option A

4. Quick Check:

   Separate UI, logic, data = Separating UI code, business logic, and data access into different modules [OK]

Hint: Keep UI, logic, data in separate files [OK]

Common Mistakes:

• Mixing UI and logic in one place
• Putting all code in one file
• Ignoring module boundaries

3. Consider this simplified code snippet applying separation of concerns:

class DataFetcher:
    def fetch(self):
        return "data"

class Processor:
    def process(self, data):
        return data.upper()

class UI:
    def display(self, processed_data):
        print(processed_data)

fetcher = DataFetcher()
data = fetcher.fetch()
processor = Processor()
processed = processor.process(data)
ui = UI()
ui.display(processed)

What will be printed when this code runs?

medium

A. processor

B. data

C. fetch

D. DATA

Solution

1. Step 1: Trace data flow through classes

   DataFetcher returns "data". Processor converts it to uppercase "DATA". UI prints it.

2. Step 2: Determine final output

   The UI prints the processed data, which is "DATA" in uppercase.

3. Final Answer:

   DATA -> Option D

4. Quick Check:

   Uppercase processed data = DATA [OK]

Hint: Follow data from fetch to display [OK]

Common Mistakes:

• Confusing original data with processed data
• Ignoring the uppercase conversion
• Thinking print shows method names

4. In a system designed with separation of concerns, which issue indicates a violation of this principle?

medium

A. Clear division of responsibilities between components

B. Separate modules for UI and data storage communicating via interfaces

C. A module handling both user input validation and database queries

D. Using interfaces to connect independent parts

Solution

1. Step 1: Identify violation of separation of concerns

   A module doing multiple unrelated jobs breaks the principle.

2. Step 2: Match options to violation

   A module handling both user input validation and database queries shows one module handling both validation and database queries, mixing concerns.

3. Final Answer:

   A module handling both user input validation and database queries -> Option C

4. Quick Check:

   Mixed responsibilities = violation [OK]

Hint: One module, one job only [OK]

Common Mistakes:

• Thinking interfaces cause violation
• Believing clear division is a problem
• Confusing separation with duplication

5. You are designing a web application with separation of concerns. Which design choice best supports this principle while ensuring scalability?

hard

A. Combine UI rendering, business logic, and data access in a single service

B. Use separate services for UI, business logic, and data storage connected via APIs

C. Store all data and logic in the client-side code for faster access

D. Avoid defining clear interfaces between components to reduce complexity

Solution

1. Step 1: Understand separation and scalability needs

   Separation means dividing concerns; scalability means easy to grow and maintain.

2. Step 2: Evaluate design options

   Use separate services for UI, business logic, and data storage connected via APIs uses separate services connected by APIs, which keeps concerns separate and supports scaling.

3. Final Answer:

   Use separate services for UI, business logic, and data storage connected via APIs -> Option B

4. Quick Check:

   Separate services + APIs = scalable separation [OK]

Hint: Separate services with APIs scale best [OK]

Common Mistakes:

• Combining all logic in one service
• Putting logic only on client side
• Skipping interfaces between parts