What Goes in a Low-Level Design Document (LLD Template)

A low-level design (LLD) document takes one part of a high-level design and describes it in enough detail that an engineer can write the code. That detail is its classes, its interfaces, its data model, its API contracts, and the sequence of calls for each main flow. The high-level design says that a rate limiter sits in front of the API. The LLD says which classes make up the rate limiter, what each method is named, which table stores the counters, and what the service returns when the limit is exceeded. The template below has eleven sections, and a document that fills all of them in is complete.

If your question was how the low-level document differs from the high-level one, that comparison is answered in LLD vs. HLD.

The eleven sections of an LLD document

1. Scope and assumptions. Name the one part being designed, the requirements it must meet, and anything you assumed because the high-level design left it open. Two or three numbered assumptions are normal.
2. Component responsibilities. State in one paragraph what this part owns and what it delegates to others. A reader should be able to tell whether a given bug belongs here.
3. Class diagram. Draw the classes, their fields, and the relationships between them, where a relationship is inheritance, composition (one object owns another), or association (one object refers to another).
4. Interfaces and method signatures. List each public method with its parameter types, its return type, and the exceptions it can throw. This is the contract other engineers code against.
5. Data model. Give each table or collection with its columns, primary key, and indexes, and state which query each index exists to serve.
6. API contracts. For each endpoint, show the request body, the response body, and every error code with the condition that produces it.
7. Sequence diagrams for the main flows. For each of the two or three most important operations, show the order of calls between classes and services from request to response.
8. Error handling and retries. State which failures are retried, how many times, with what delay, and which are returned to the caller at once.
9. Concurrency and locking. Name every piece of state that two threads or two servers can write at the same time, and say how the race is prevented: a lock, an atomic operation, or a version check.
10. Logging and metrics. List the log lines and counters this part emits, so the on-call engineer can tell whether it is healthy.
11. Open questions. Record what is undecided and who decides it, so the reviewer does not report it as a defect.

A worked example: rate limiter service

Scope: limit each API key to 100 requests per minute across all servers, and assume keys are already authenticated. Responsibility: answer allow or deny for one request in under 2 ms, and never block the request on a slow store. Classes: RateLimiter, TokenBucket, BucketStore, and one LimitPolicy per key. Signatures: boolean allow(String apiKey) and void configure(String apiKey, LimitPolicy policy). Data model: one hash per key in Redis, an in-memory key-value store, holding the token count and the last refill time, with a 120-second expiry. API contract: the service returns 429 with a Retry-After header when a bucket is empty. Sequence: the gateway calls allow, RateLimiter loads the bucket, refills tokens for the elapsed time, takes one, and writes back. Concurrency: refill and take run as one atomic operation inside the store, so two servers cannot both spend the last token. Metrics: allowed, denied, and store latency per key.