How to Write a Good Low-Level Design (LLD) Document

LLD stands for low-level design. An LLD document describes how one module will be built: its classes with their fields and methods, its data structures, its database tables, and the sequence of calls for each operation. It is written after the high-level design (HLD), which fixes the major parts of the system and how they communicate, and before any code. The test of a good LLD is simple: a programmer who did not attend the design meetings can implement the module from the document without asking a question. For one service, that usually means 5 to 15 pages with one class diagram, one table per entity, and one sequence diagram per main flow.

HLD vs LLD

The HLD says "orders are stored in PostgreSQL and payments are processed by a separate service". The LLD says which tables hold orders, which class validates them, what the payment client interface looks like, and what happens when the payment service times out after 3 seconds.

The LLD document template

A low-level design document should contain the sections below, in this order. Skip a section only when you state why it does not apply.

1. Title and metadata. Module name, author, reviewers, version, and status (draft, in review, approved).
2. Purpose and scope. Which HLD requirements this module satisfies, and what is out of scope.
3. Assumptions and constraints. Language, framework, limits such as 1,000 requests per second, and dependencies on other modules.
4. Module overview. One diagram of this module and its neighbors, with the interfaces between them named.
5. Class design. A class diagram, then one subsection per class: its single responsibility, fields, public methods with signatures, and relationships (inheritance, composition, association).
6. Data design. Tables with columns, types, primary and foreign keys, indexes, and constraints. For in-memory structures, the structure and the time complexity of each operation.
7. Interfaces and APIs. Each endpoint or public method: input, output, validation rules, and error codes.
8. Sequence diagrams. One per main use case, showing the calls between classes in order.
9. Error handling and edge cases. What each failure returns, what is retried, and what is logged.
10. Concurrency and performance. Shared state, locks or versioning, expected latency, and the limiting resource.
11. Security, logging, and configuration. Authorization checks, what is logged, and which values are configurable.
12. Test plan and open questions. Unit and integration tests planned, plus decisions still waiting for an answer.

A short example: a parking lot ticketing module

The HLD requirement is "issue a ticket when a vehicle enters, assign a spot that fits, and charge on exit". The LLD for that module names four classes and one table.

class ParkingLot {
  Ticket enter(Vehicle v);            // throws LotFullException
  Receipt exit(String ticketId);      // throws TicketNotFoundException
}

class SpotAllocator {
  Optional<Spot> findSpot(VehicleSize size);   // O(1) per size, one free-list per size
  void release(Spot s);
}

class Ticket {
  String id; String plate; String spotId; long entryEpochMs;
}

interface PricingStrategy {           // Strategy pattern: hourly, flat, or event pricing
  long priceInCents(long entryEpochMs, long exitEpochMs);
}

CREATE TABLE tickets (
  id          CHAR(12) PRIMARY KEY,
  plate       VARCHAR(16) NOT NULL,
  spot_id     VARCHAR(8)  NOT NULL,
  entry_ms    BIGINT      NOT NULL,
  exit_ms     BIGINT,
  amount_cents INT,
  CONSTRAINT one_open_ticket_per_spot UNIQUE (spot_id, exit_ms)
);

The sequence for entry is: the gate calls ParkingLot.enter, which asks SpotAllocator.findSpot for the smallest free spot that fits, inserts a ticket row, and returns the ticket. The edge cases section states that a full lot returns an error within 50 milliseconds and that two gates requesting the last spot at the same time are serialized by a lock on the free-list. The pricing strategy is an interface so that a new pricing rule is a new class rather than a change to exit.

What separates a good LLD from a weak one

Every requirement is traceable. Each HLD requirement appears in the scope section and is met by a named class or table.

Every class has one responsibility. A class named Manager or Helper that does five things is a sign that the design has not been finished.

Every public method has a contract. Inputs, outputs, errors, and, for anything that iterates, the time complexity. "Handles the request appropriately" is not a contract.

Design patterns are named with a reason. "Strategy, so that pricing rules change without touching the exit flow" is useful. A list of patterns without reasons is not.

Diagrams and text agree. A class in the diagram that is absent from the text, or the reverse, is the most common defect found in review.

LLD in an interview

An LLD or object-oriented design interview compresses the document into 45 to 60 minutes of conversation. The order is the same: clarify the requirements for 5 minutes, list the entities, draw the class diagram with relationships, walk through the two main flows, and then extend the design when the interviewer adds a requirement. Parking lot, library management, elevator system, and a movie ticket booking system are the questions asked most often, and each one fits the template above.