What is low-level design?

You open a food delivery app, pick a dosa and pay. The app then shows each step: placed, picked up, delivered.

Somebody decided which classes make that work, what each one stores, and which methods it has. That decision is low-level design. This course teaches you to make it, in an interview and at work.

From an idea to code

Software takes four steps from an idea to code. Each step zooms in on the one above it.

• High-level design (HLD) draws the big boxes: an order service, a payment service, a database. It asks how they scale and talk over the network.
• Low-level design (LLD) opens one box. It names the classes inside, what each one stores, and how they call each other.

So LLD sits between the boxes and the code. You can write code without it, but the first change request shows the cost.

What an LLD interview asks

You get a short prompt, such as "design a parking lot", and about 45 minutes. The prompt is vague on purpose. The interviewer wants to watch you turn it into classes.

They judge five things:

Some rounds end at a class diagram. Others ask you to code the core classes. This course prepares you for both.

One requirement, start to finish

Read the requirement

Here is a small one, the size of an interview warm-up:

A customer orders a dish from a restaurant. A delivery partner picks the order up and delivers it. The customer can see the order's status at any time.

Nouns become classes, verbs become methods

Underline the nouns and the verbs. Nouns are candidate classes. Verbs are candidate methods, on the class that owns the data they change.

Two words did not become what you might expect:

• Status is a fact about one order. So it is a field of Order, with three values, not a class of its own.
• Picks up is something the partner does, but it changes the order's status. So the method lives on Order, and the partner calls it.

The rule behind both: a method lives with the data it changes.

Draw the classes

┌────────────────────────────────────────────────────┐
│                                                    │
│   ┌─────────────────┐  uses  ┌─────────────────┐   │
│   │ Customer        ├───────▶│ Restaurant      │   │
│   ├─────────────────┤        ├─────────────────┤   │
│   │ placeOrder()    │        │ find(dish)      │   │
│   └────────┬────────┘        └────────●────────┘   │
│            │ uses                     │ owns       │
│            ▼                          │            │
│   ┌─────────────────┐  has   ┌────────┴────────┐   │
│   │ Order           │        │ MenuItem        │   │
│   ├─────────────────┤        ├─────────────────┤   │
│   │ - items         ○────────┤ name            │   │
│   │ - status        │        │ price           │   │
│   ├─────────────────┤        └─────────────────┘   │
│   │ markPickedUp()  │                              │
│   │ markDelivered() │                              │
│   │ getStatus()     │                              │
│   └─────────────────┘                              │
│            ▲                                       │
│            │ uses                                  │
│   ┌────────┴────────┐                              │
│   │ DeliveryPartner │                              │
│   ├─────────────────┤                              │
│   │ pickUp(order)   │                              │
│   │ deliver(order)  │                              │
│   └─────────────────┘                              │
│                                                    │
│    ──▶ uses   ●── owns   ○── has   - private       │
│                                                    │
└────────────────────────────────────────────────────┘

Each box has the class name on top, then its fields, then its methods. The lines say how classes depend on each other:

• Uses (──▶): Customer calls Restaurant.find() and creates an Order. DeliveryPartner calls methods on an Order.
• Owns (●──): a restaurant owns its menu. Remove the restaurant, and its menu items go too.
• Has (○──): an order points at menu items, but the items live on after the order is done.

Read and draw class diagrams covers these lines in detail. For now, read each one as a short sentence.

Watch the objects talk

A class diagram shows who knows whom. It does not show the order of the calls. A sequence diagram does.

Notice that every status change goes through Order. Nobody else writes to status.

The code

Here are Order and Customer, the two classes at the heart of the flow:

JavaPythonTypeScript

enum Status { PLACED, PICKED_UP, DELIVERED }

class Order {
    private final List<MenuItem> items;
    private Status status = Status.PLACED;

    Order(List<MenuItem> items) { this.items = items; }

    void markPickedUp() { status = Status.PICKED_UP; }
    void markDelivered() { status = Status.DELIVERED; }
    Status getStatus() { return status; }
}

class Customer {
    private final String name;

    Customer(String name) { this.name = name; }

    Order placeOrder(Restaurant restaurant, String dish) {
        MenuItem item = restaurant.find(dish);
        return new Order(List.of(item));
    }
}

• status is private. Only the three methods of Order touch it, so no other class can set a wrong value.
• placeOrder asks the restaurant for the item, then creates the order. The customer never builds a MenuItem itself.
• Restaurant, MenuItem and DeliveryPartner follow the same shape. A run of the whole flow prints PLACED, PICKED_UP, DELIVERED.
• In TypeScript, a union of three strings does the job of the enum. In Python, a leading underscore marks a field as private.

Five moves for every problem

You made most of these moves above. The course uses the same five on every problem.

┌────────────────────────────────────────────────┐
│                                                │
│   1  requirements    what must it do?          │
│            ▼                                   │
│   2  entities        which classes exist?      │
│            ▼                                   │
│   3  relationships   who owns, has, uses?      │
│            ▼                                   │
│   4  patterns        does a known shape fit?   │
│            ▼                                   │
│   5  code            the core classes, run     │
│                                                │
└────────────────────────────────────────────────┘

1. Requirements. Write what the system must do, and ask about the limits.
2. Entities. Pick classes from the nouns. Give each one job.
3. Relationships. Draw the lines: owns, has, uses, extends.
4. Patterns. Look for a problem with a known answer, such as "many ways to pay".
5. Code. Write the core classes and run the main flow.

The order app skipped move 4. Three statuses and one kind of partner need no pattern. A pattern earns its place only when a change request needs it. Part two of the course shows when.

How this course works

Three parts

The parts follow the order of the takeUforward LLD sheet. The last part designs and then codes 12 classic problems, such as a parking lot and an elevator.

One path in every lesson

Each principle and pattern lesson walks the same path:

1. The problem: code that works today, then a change request that hurts it.
2. The idea: the principle in one sentence, and a class diagram.
3. The fix: the same code, rebuilt, so the change request becomes one new class.
4. How it runs: the objects calling each other, as a sequence diagram.
5. When to use it: the signals in a requirement, and when it is too much.

Code in three languages

Every code block has Java, Python and TypeScript tabs. Pick one once, and every block on the site follows it.

• The three versions use the same names: camelCase in Java and TypeScript, snake_case in Python.
• Each version was run, and all three print the same output.
• Abstract types are interfaces in Java and TypeScript, and abc.ABC classes in Python.

Read more

• takeUforward LLD sheet, the order this course follows
• Object-oriented programming concepts, the Java tutorial's short tour of objects and classes
• The PaymentIntents API and its status lifecycle, a real design built from nouns and verbs

Next: objects, classes and the four pillars, on a payments module you can run.