Part 1 ~ Top 10 Low-Level Design Questions

These are my personal notes after reading several Low-Level Design (LLD) interview materials. I rewrote them in a simpler way so they're easier to review before interviews.

1. What is Low-Level System Design?

Low-Level Design (LLD) is the process of turning a high-level architecture into actual software components that developers can implement.

Instead of discussing what the system should do, LLD focuses on how each part works internally.

Usually, it includes:

Classes and objects
Relationships between objects
APIs
Internal business logic
Responsibilities of each module

A good LLD helps reduce ambiguity before coding starts. It also makes the system easier to maintain, extend, and scale.

Example

Suppose we're building a Parking Lot system.

Instead of saying:

"The system should manage parking."

LLD defines things like:

Car
ParkingSpot
ParkingTicket
ParkingLot

Each class has its own responsibility and knows how to interact with the others.

---
config:
  look: handDrawn
---
classDiagram
    class ParkingLot{
        +parkCar()
        +removeCar()
    }

    class ParkingSpot{
        +spotId
        +isAvailable
    }

    class Car{
        +plateNumber
    }

    class ParkingTicket{
        +ticketId
        +entryTime
    }

    ParkingLot --> ParkingSpot
    ParkingLot --> ParkingTicket
    ParkingSpot --> Car

2. How Database Indexing Improves Performance

A database index is an additional data structure that helps the database find rows much faster.

Without an index, the database usually scans every row (Full Table Scan).

With an index, it can jump directly to the desired location.

Common index structures include:

B-Tree
Hash Index
Bitmap Index

Benefits:

Faster SELECT
Better filtering
Faster JOIN operations
Efficient range queries
Less disk I/O

Example

Imagine a users table with one million records.

Searching by user_id without an index means checking rows one by one.

With an index, it's similar to using a book's table of contents—you can immediately jump to the correct page.

---
config:
  look: handDrawn
---
flowchart LR
    A[Query user_id=1001] --> B{Index Exists?}

    B -->|Yes| C[Go directly to row]
    B -->|No| D[Scan entire table]

    C --> E[Fast]
    D --> F[Slow]

3. Four Pillars of Object-Oriented Programming

Object-Oriented Programming (OOP) is built on four core principles.

Encapsulation

Hide internal data and expose only what is necessary.

Instead of allowing direct access to variables, objects provide methods.

balance = private
deposit()
withdraw()

Abstraction

Hide unnecessary implementation details.

Users only know what a function does, not how it works internally.

Example:

car.start()

You don't care how the engine starts internally.

Inheritance

A class can inherit common functionality from another class.

Instead of rewriting code, child classes reuse the parent's behavior.

Account
├── SavingsAccount
└── CurrentAccount

Polymorphism

Different objects can respond differently to the same method.

Example:

payment.pay()

CreditCard.pay()
Paypal.pay()
BankTransfer.pay()

Same interface.

Different implementations.

4. Why Concurrency Control Matters

Modern applications often run multiple threads simultaneously.

If multiple threads modify the same data at the same time, problems may occur.

Common issues include:

Race Condition
Deadlock
Data corruption
Lost updates

Concurrency control ensures shared resources remain consistent.

Banking Example

Initial balance:

$100

Two users withdraw $80 simultaneously.

Without synchronization:

Both read $100
Both approve withdrawal
Final balance = $20 ❌

The system accidentally allows withdrawing $160.

With proper locking:

---
config:
  theme: redux-color-dark
  look: handDrawn
---
sequenceDiagram
    participant T1
    participant Account
    participant T2

    T1->>Account: Lock
    T1->>Account: Withdraw $80
    Account-->>T1: Success
    T1->>Account: Unlock

    T2->>Account: Lock
    T2->>Account: Balance = $20
    Account-->>T2: Reject

5. What are UML Behavioral Diagrams?

Behavioral diagrams describe how a system behaves during execution.

Instead of showing classes, they show:

interactions
workflows
state changes
message flow

Common behavioral diagrams include:

Sequence Diagram
Activity Diagram
State Diagram
Use Case Diagram

These diagrams help developers understand how the application behaves over time.

6. UML Sequence Diagram for User Login

A Sequence Diagram shows interactions between components in chronological order.

For a login process:

User submits credentials.
Controller receives the request.
Authentication service validates it.
Database checks the user.
Result is returned.

---
config:
  theme: redux-color-dark
  look: handDrawn
---
sequenceDiagram
    actor User
    participant UI
    participant AuthService
    participant Database

    User->>UI: Enter username & password
    UI->>AuthService: Login request
    AuthService->>Database: Verify credentials
    Database-->>AuthService: User found
    AuthService-->>UI: JWT / Success
    UI-->>User: Login successful

This is one of the most common UML diagrams in interviews.

7. UML State Diagram

A State Diagram describes how an object changes over time.

Each event moves the object from one state to another.

Example: Payment lifecycle.

---
config:
  look: handDrawn
---
stateDiagram-v2
    [*] --> Pending
    Pending --> Processing
    Processing --> Completed
    Processing --> Failed
    Completed --> [*]
    Failed --> [*]

State diagrams are useful for:

Orders
Payments
Sessions
Ticket booking
Workflow systems

8. Choosing the Right Data Structure

Selecting the right data structure is important because it directly affects performance.

Things to consider:

Read frequency
Write frequency
Memory usage
Lookup speed
Concurrency
Scalability

Some common choices:

Use Case	Data Structure	Why
Cache	HashMap	O(1) lookup
Message Queue	Queue	FIFO processing
Priority Scheduling	Heap	Fast priority retrieval
Ordered Data	Tree	Sorted traversal
Undo Feature	Stack	LIFO behavior

There is no universally "best" data structure. The right choice depends on the problem you're solving.

9. Benefits of Database Normalization

Normalization organizes database tables to reduce duplicated data.

Instead of storing the same information repeatedly, related data is separated into different tables.

Benefits include:

Less duplicate data
Better consistency
Easier updates
Smaller storage requirements
Fewer update anomalies

Instead of this:

Orders

OrderID
CustomerName
CustomerPhone
CustomerAddress

Use:

Customers
-----------
CustomerID
Name
Phone

Orders
-----------
OrderID
CustomerID

---
config:
  look: handDrawn
---
erDiagram
    CUSTOMER ||--o{ ORDER : places

    CUSTOMER {
        int customer_id
        string name
        string phone
    }

    ORDER {
        int order_id
        int customer_id
    }

Now customer information exists in only one place.

10. Designing an Efficient Logging & Monitoring System

Logging and monitoring provide visibility into what happens inside an application.

Without them, debugging production issues becomes much harder.

A good observability system usually includes:

Structured logging
Log levels
Centralized log storage
Metrics
Dashboards
Alerts

Common log levels:

DEBUG
INFO
WARN
ERROR
FATAL

For microservices, a Correlation ID is commonly used.

Every service includes the same request ID so the entire request flow can be traced.

---
look: handDrawn
---
flowchart LR
    Client --> API
    API --> UserService
    UserService --> PaymentService
    PaymentService --> Database

    API -. Correlation ID .-> UserService
    UserService -. Correlation ID .-> PaymentService
    PaymentService -. Correlation ID .-> Database

Popular tools include:

ELK Stack
Grafana
Prometheus
Loki
OpenTelemetry

Together, they help engineers quickly identify performance bottlenecks, failures, and unexpected behaviors.

Final Thoughts

Most Low-Level Design interviews aren't about memorizing definitions. They're about understanding why a particular design decision makes sense.

When practicing LLD, always ask yourself:

Why is this class needed?
Why choose this data structure?
Will this design still work if traffic grows 100×?
Can someone else easily understand and extend this code later?

Good software design is all about balancing simplicity, maintainability, and scalability.