DRY (Don't Repeat Yourself) in LLD - System Design Exercise

Design: DRY Principle Implementation in Software Design

Focus on design patterns and architecture to enforce DRY in code and system components. Out of scope: specific programming language syntax or IDE tooling.

Functional Requirements

FR1: Avoid code duplication across the system

FR2: Ensure maintainability by centralizing repeated logic

FR3: Support easy updates without changing multiple places

FR4: Promote reusability of components and modules

Non-Functional Requirements

NFR1: System should handle up to 1000 concurrent users

NFR2: Code changes should propagate with minimal risk of bugs

NFR3: Latency impact of abstraction layers should be minimal (<5ms overhead)

NFR4: Maintain 99.9% uptime for critical services

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

Key Components

Reusable modules or libraries

Service layers or APIs

Configuration management

Shared databases or caches

Design Patterns

Modularization

Service-Oriented Architecture (SOA)

Template Method pattern

Decorator pattern

Inheritance and composition

Reference Architecture

  +-------------------+       +-------------------+       +-------------------+
  |  Client Layer     | <---> |  Service Layer    | <---> |  Shared Modules   |
  +-------------------+       +-------------------+       +-------------------+
                                   |                             |
                                   v                             v
                          +-------------------+         +-------------------+
                          |  Database Layer   |         |  Configuration    |
                          +-------------------+         +-------------------+

Components

Client Layer

Any frontend or API client

Consume services without duplicating business logic

Service Layer

REST/gRPC services or application logic modules

Centralize business logic to avoid repetition

Shared Modules

Reusable libraries or packages

Provide common utilities and helpers used across services

Database Layer

Relational or NoSQL database

Store data centrally to avoid duplication

Configuration

Central config management (e.g., Consul, etcd)

Manage shared settings to prevent repeated hardcoded values

Request Flow

1. Client sends request to Service Layer

2. Service Layer calls Shared Modules for common logic

3. Service Layer queries Database Layer for data

4. Service Layer uses Configuration service for settings

5. Service Layer returns response to Client

Database Schema

Entities: User, Product, Order Relationships: - User 1:N Order - Order N:1 Product All shared data stored centrally to avoid duplication in multiple places.

Scaling Discussion

Bottlenecks

Shared modules becoming a single point of failure

Service Layer overloaded with requests

Database contention due to centralized data

Configuration service latency impacting startup or runtime

Solutions

Deploy shared modules as distributed libraries or microservices with redundancy

Use load balancers and horizontal scaling for Service Layer

Implement database sharding and caching layers

Use highly available configuration stores with local caching

Interview Tips

Time: 10 minutes to clarify requirements and constraints, 20 minutes to design architecture and data flow, 15 minutes to discuss scaling and trade-offs

Explain the importance of avoiding code duplication for maintainability

Describe how centralizing logic reduces bugs and eases updates

Discuss trade-offs between DRY and over-abstraction

Highlight how shared modules and configuration help enforce DRY

Address scaling challenges and solutions for centralized components

Practice

1. What is the main goal of the DRY principle in system design?

easy

A. To avoid repeating code or design to keep systems simple

B. To write as much code as possible for clarity

C. To duplicate modules for faster development

D. To create multiple versions of the same component

Solution

1. Step 1: Understand the meaning of DRY

   DRY stands for "Don't Repeat Yourself," which means avoiding repeated code or design.

2. Step 2: Identify the goal of DRY

   The goal is to keep systems simple, maintainable, and reduce bugs by reusing components.

3. Final Answer:

   To avoid repeating code or design to keep systems simple -> Option A

4. Quick Check:

   DRY = Avoid repetition [OK]

Hint: DRY means write once, use many times [OK]

Common Mistakes:

• Thinking DRY means writing more code
• Believing duplication speeds development
• Confusing DRY with writing multiple versions

2. Which of the following is a correct way to follow DRY in system design?

easy

A. Creating reusable components or modules

B. Ignoring code reuse to save time

C. Writing separate code for each similar task

D. Copy-pasting the same code in multiple modules

Solution

1. Step 1: Identify DRY best practice

   DRY encourages reuse by creating components or modules that can be used multiple times.

2. Step 2: Evaluate options

   Copy-pasting or writing separate code repeats work, which breaks DRY. Ignoring reuse wastes effort.

3. Final Answer:

   Creating reusable components or modules -> Option A

4. Quick Check:

   Reuse = DRY [OK]

Hint: Reuse code with modules/components [OK]

Common Mistakes:

• Copy-pasting code instead of reusing
• Writing separate code for similar tasks
• Ignoring reuse to save time

3. Consider this pseudocode snippet following DRY:

function calculateTax(amount) {
  return amount * 0.1;
}

function calculateTotal(amount) {
  return amount + calculateTax(amount);
}

print(calculateTotal(100));

What is the output?

medium

A. 10

B. 100

C. 110

D. Syntax Error

Solution

1. Step 1: Calculate tax for amount 100

   Tax = 100 * 0.1 = 10

2. Step 2: Calculate total using tax

   Total = 100 + 10 = 110

3. Final Answer:

   110 -> Option C

4. Quick Check:

   100 + 10 = 110 [OK]

Hint: Add tax to amount using reusable function [OK]

Common Mistakes:

• Forgetting to add tax to amount
• Confusing tax amount with total
• Assuming syntax error without checking code

4. You see this code snippet violating DRY:

function sendEmailToUser1() {
  // send email logic
}

function sendEmailToUser2() {
  // send email logic
}

What is the best fix to follow DRY?

medium

A. Copy-paste send email logic in more functions

B. Create one function sendEmail(user) and reuse it

C. Keep both functions as is for clarity

D. Remove email sending completely

Solution

1. Step 1: Identify repeated code

   Both functions have the same email sending logic repeated.

2. Step 2: Refactor to reusable function

   Create one function with a parameter for user to reuse the logic.

3. Final Answer:

   Create one function sendEmail(user) and reuse it -> Option B

4. Quick Check:

   Refactor repeated code = DRY [OK]

Hint: Use parameters to reuse functions [OK]

Common Mistakes:

• Leaving duplicate functions unchanged
• Copy-pasting code more times
• Removing needed functionality

5. You design a system with multiple services needing user authentication. To follow DRY, which approach is best?

hard

A. Implement authentication logic separately in each service

B. Skip authentication to reduce complexity

C. Copy authentication code into each service for speed

D. Create a shared authentication service used by all services

Solution

1. Step 1: Identify repeated authentication logic

   Multiple services need the same authentication, so repeating code breaks DRY.

2. Step 2: Use a shared authentication service

   Centralizing authentication logic in one service allows reuse and easier maintenance.

3. Final Answer:

   Create a shared authentication service used by all services -> Option D

4. Quick Check:

   Shared service = DRY in system design [OK]

Hint: Centralize common logic in shared services [OK]

Common Mistakes:

• Duplicating authentication code in each service
• Skipping authentication for simplicity
• Copy-pasting code instead of sharing