YAGNI (You Aren't Gonna Need It) in LLD - System Design Exercise

Design: YAGNI Principle Application in System Design

Focus on designing a system or component applying YAGNI principle. Out of scope: predicting future features or building complex abstractions upfront.

Functional Requirements

FR1: Design a simple feature or system component that meets current needs only

FR2: Avoid adding extra features or complexity that are not immediately required

FR3: Ensure the system is easy to maintain and extend later if needed

Non-Functional Requirements

NFR1: Keep design minimal and focused on current requirements

NFR2: Avoid over-engineering or premature optimization

NFR3: Design should be scalable but not overly complex initially

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

Key Components

Core functional modules that fulfill current requirements

Interfaces that allow easy extension later

Simple data models without unnecessary fields

Basic error handling and validation

Design Patterns

Incremental design

Modular design

Open-closed principle (open for extension, closed for modification)

Avoid premature optimization

Reference Architecture

  +-------------------+
  |   User Request    |
  +---------+---------+
            |
            v
  +-------------------+
  |  Core Functionality|
  |  (Meets current   |
  |   requirements)   |
  +---------+---------+
            |
            v
  +-------------------+
  |  Data Storage     |
  |  (Minimal schema) |
  +-------------------+

Components

User Interface

Any frontend or API layer

Accepts user input and sends requests to core functionality

Core Functionality

Simple service or module

Implements only the features required now, no extras

Data Storage

Relational or NoSQL database

Stores only necessary data fields to support current features

Request Flow

1. User sends a request to perform a needed action

2. Core functionality processes the request using minimal logic

3. Data storage is accessed or updated with only required data

4. Response is sent back to the user

Database Schema

Entities have only fields needed for current features. For example, a User entity with id, name, and email only if those are required now. No extra fields or tables for future anticipated features.

Scaling Discussion

Bottlenecks

Adding features later may require refactoring if initial design is too minimal

Performance may degrade if minimal design does not consider scaling at all

Integration with other systems might be harder if interfaces are too simple

Solutions

Design modular components with clear interfaces to allow easy extension

Use abstraction layers that can be enhanced without changing core logic

Add caching or load balancing only when needed, not upfront

Refactor iteratively as new requirements emerge

Interview Tips

Time: Spend 10 minutes understanding requirements and clarifying scope, 20 minutes designing a minimal system applying YAGNI, 15 minutes discussing trade-offs and scaling

Explain importance of focusing on current needs to avoid wasted effort

Show how minimal design reduces complexity and maintenance cost

Discuss how to keep design flexible for future without over-engineering

Highlight trade-offs between simplicity now and extensibility later

Practice

1. What does the YAGNI principle primarily encourage in system design?

easy

A. Build only features you currently need

B. Plan and build all possible future features

C. Add complex layers for scalability upfront

D. Write extra code for potential edge cases

Solution

1. Step 1: Understand YAGNI meaning

   YAGNI stands for "You Aren't Gonna Need It" and advises to avoid building features before they are necessary.

2. Step 2: Match principle to options

   Build only features you currently need matches the idea of building only what is needed now, while others suggest building for future or complexity.

3. Final Answer:

   Build only features you currently need -> Option A

4. Quick Check:

   YAGNI = Build only what you need now [OK]

Hint: YAGNI means avoid future guesswork, build now only [OK]

Common Mistakes:

• Thinking YAGNI means planning for all future needs
• Confusing YAGNI with over-engineering
• Assuming YAGNI discourages any planning

2. Which of the following is the correct way to apply YAGNI when designing a new feature in a system?

easy

A. Add detailed logging for every possible error before deployment

B. Design the database schema to handle all future data types

C. Write unit tests for features you plan to add later

D. Implement only the core functionality needed for the feature now

Solution

1. Step 1: Identify core YAGNI practice

   YAGNI advises to implement only what is necessary now, avoiding premature additions.

2. Step 2: Evaluate options for current need focus

   Implement only the core functionality needed for the feature now focuses on core functionality now, while others add future or unnecessary work.

3. Final Answer:

   Implement only the core functionality needed for the feature now -> Option D

4. Quick Check:

   YAGNI = Build core now, skip extras [OK]

Hint: Focus on core feature first, skip extras [OK]

Common Mistakes:

• Adding features or tests for future needs
• Over-engineering database for unknown data
• Writing unnecessary logs before real errors occur

3. Consider this scenario: A team adds a caching layer anticipating high traffic, but the system never reaches that load. What does this violate in terms of YAGNI?

medium

A. They avoided unnecessary complexity

B. They followed YAGNI by preparing for future needs

C. They built a feature they didn't need yet

D. They simplified the system by adding cache

Solution

1. Step 1: Analyze the caching layer addition

   The team added caching before it was needed, anticipating future load.

2. Step 2: Relate to YAGNI principle

   YAGNI discourages building features before they are actually needed, so this is a violation.

3. Final Answer:

   They built a feature they didn't need yet -> Option C

4. Quick Check:

   YAGNI violation = building unneeded features [OK]

Hint: Building features before need breaks YAGNI [OK]

Common Mistakes:

• Thinking preparing for future is YAGNI
• Confusing simplification with premature optimization
• Assuming caching always simplifies system

4. A developer added a complex permission system anticipating many user roles, but the product currently has only one role. What is the main issue here related to YAGNI?

medium

A. The developer ignored YAGNI by adding unnecessary complexity

B. The permission system is too simple for current needs

C. The system is scalable and follows YAGNI

D. The product requires multiple roles immediately

Solution

1. Step 1: Identify the developer's action

   The developer added a complex system for roles not currently needed.

2. Step 2: Connect to YAGNI principle

   YAGNI advises against adding complexity before it's necessary, so this is a violation.

3. Final Answer:

   The developer ignored YAGNI by adding unnecessary complexity -> Option A

4. Quick Check:

   Unneeded complexity violates YAGNI [OK]

Hint: Avoid complexity until it's truly needed [OK]

Common Mistakes:

• Assuming scalability means following YAGNI
• Believing all future roles must be planned now
• Confusing simple with insufficient

5. You are designing a messaging system. You consider adding encryption support now, but the current users do not require it. According to YAGNI, what should you do?

hard

A. Implement encryption now to avoid future rework

B. Skip encryption for now and add it when users need it

C. Design the system assuming all messages are encrypted

D. Build a complex key management system upfront

Solution

1. Step 1: Understand current user needs

   Users do not require encryption now, so it is not immediately necessary.

2. Step 2: Apply YAGNI principle to design decision

   YAGNI advises to avoid building features before they are needed, so skip encryption now.

3. Final Answer:

   Skip encryption for now and add it when users need it -> Option B

4. Quick Check:

   YAGNI = build features only when needed [OK]

Hint: Add features only when users actually need them [OK]

Common Mistakes:

• Building features just to avoid future work
• Assuming all users need encryption immediately
• Over-engineering system upfront