Introduction to Low Level Design

Overview

Low Level Design (LLD) is the process of designing the internal structure of a software system at the class and method level. It bridges the gap between high-level architecture decisions and actual code implementation. LLD focuses on how individual components are built, how they interact, and how they fulfill the system's requirements through well-defined interfaces, data structures, and algorithms.

In interviews, LLD tests your ability to translate a vague problem statement into a clean, extensible, and maintainable object-oriented design.

---

What is Low Level Design?

LLD answers the question: "How do we build this?"

It involves:

• Identifying classes, interfaces, and their relationships
• Defining method signatures and data members
• Choosing appropriate design patterns
• Handling edge cases, concurrency, and error scenarios
• Making trade-off decisions between simplicity and extensibility

---

HLD vs LLD - Comparison

---

When Does LLD Matter?

1. Interviews - Most companies (FAANG, startups, product companies) have a dedicated LLD round
2. Day-to-day engineering - Every feature you build requires class-level design decisions
3. Code reviews - Reviewers evaluate your design choices, not just correctness
4. Technical debt - Poor LLD leads to rigid, fragile code that's expensive to change
5. Team collaboration - Good LLD makes code readable and modifiable by others

---

Key Skills Tested in LLD Interviews

+---------------------------------------------------+
|           LLD Interview Skill Matrix              |
+---------------------------------------------------+
|                                                   |
|  1. Object-Oriented Thinking                      |
|     - Identify entities and relationships         |
|     - Encapsulation, abstraction                  |
|                                                   |
|  2. Design Principles                             |
|     - SOLID principles                            |
|     - DRY, KISS, YAGNI                           |
|                                                   |
|  3. Design Patterns                               |
|     - Creational, Structural, Behavioural         |
|     - Know when to apply (not just what)          |
|                                                   |
|  4. Trade-off Analysis                            |
|     - Simplicity vs extensibility                 |
|     - Performance vs readability                  |
|                                                   |
|  5. Communication                                 |
|     - Clarify requirements                        |
|     - Explain decisions                           |
|     - Handle follow-up questions                  |
|                                                   |
+---------------------------------------------------+

---

The LLD Interview Process

Step-by-Step Framework

Step 1: Clarify Requirements (5 min)
    |
    v
Step 2: Identify Core Entities (5 min)
    |
    v
Step 3: Define Relationships (5 min)
    |
    v
Step 4: Design Class Diagram (10 min)
    |
    v
Step 5: Write Key Methods (15 min)
    |
    v
Step 6: Handle Edge Cases & Extensions (5 min)

What Interviewers Look For

---

Core Concepts You Must Know

1. Object-Oriented Programming Pillars

2. Relationships Between Classes

+------------------+
|   Association    |  "uses"  -  Teacher uses Classroom
+------------------+
         |
         v
+------------------+
|   Aggregation    |  "has"  -  Department has Employees (can exist independently)
+------------------+
         |
         v
+------------------+
|   Composition    |  "owns"  -  House owns Rooms (cannot exist independently)
+------------------+
         |
         v
+------------------+
|   Inheritance    |  "is-a"  -  Dog is an Animal
+------------------+
         |
         v
+------------------+
|  Dependency      |  "depends on"  -  Order depends on PaymentService
+------------------+

3. Interface vs Abstract Class

---

Common Mistakes in LLD Interviews

1. Not asking questions - Jumping straight into design without clarifying scope
2. Over-engineering - Adding patterns/abstractions that aren't needed
3. Under-engineering - Hardcoding values, no extensibility at all
4. Ignoring edge cases - Not considering null, empty, concurrent access
5. Poor naming - Using vague names like DataManager, Utils, Helper
6. God classes - One class doing everything
7. Tight coupling - Classes directly depending on concrete implementations
8. Not thinking about concurrency - Ignoring thread safety in shared resources

---

Interview Follow-ups

Q&A Style

Q: What's the difference between LLD and coding rounds?

A: LLD focuses on design decisions - class structure, relationships, patterns, and extensibility. You may write pseudocode but the emphasis is on "why" not "how to compile." Coding rounds test algorithmic thinking, data structures, and working code. LLD tests software engineering maturity.

Q: How much code should I write in an LLD interview?

A: Write enough to demonstrate your design works. Key method signatures, core logic for 2-3 critical flows, and pseudocode for complex algorithms. Don't write getters/setters or boilerplate. Focus on the interesting parts - state transitions, pattern implementations, and business logic.

Hints for Self-Practice

Q: When would you choose composition over inheritance in your design?

• Think about "is-a" vs "has-a" relationships
• Consider what happens when requirements change
• Think about the diamond problem
• Consider testing implications

Q: How do you decide the granularity of your classes?

• Think about Single Responsibility Principle
• Consider what changes together vs what changes independently
• Think about reusability across different contexts

---

Counter Questions to Ask Interviewer

• "Should I focus on the core flow or handle all edge cases?"
• "Is concurrency a concern for this system?"
• "Should I optimize for read-heavy or write-heavy usage?"
• "Are there any specific design patterns you'd like me to consider?"
• "Should I design for a single instance or distributed deployment?"

---

References & Further Reading

• "Clean Code" by Robert C. Martin - Naming, functions, classes
• "Design Patterns: Elements of Reusable Object-Oriented Software" (GoF) - The foundational patterns book
• "Head First Design Patterns" by Eric Freeman - Accessible pattern explanations
• "Refactoring" by Martin Fowler - Improving existing designs
• "Object-Oriented Software Construction" by Bertrand Meyer - Design by Contract, OOP theory

---

Related Topics

• Software Design Principles
• Single Responsibility Principle
• Introduction to Design Patterns
• How to Approach a LLD Interview