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