What is LLD?

Low-level design is the step that turns "the system needs to do X" into the actual classes, interfaces, methods and objects that do X. If system design decides which services exist and how they talk to each other, LLD decides what lives inside one of those services: what the objects are called, what data they hold, and which of them calls which.

In interview shorthand, LLD and "object-oriented design" (OOD) are usually the same conversation. When a job posting or an interviewer says "OOD round", they mean this level of design - modeling a problem as a set of collaborating classes rather than as a diagram of boxes and arrows on a whiteboard representing services.

Same problem, two altitudes

Take "design a parking lot." At the system-design altitude, the conversation is about services and their responsibilities: an entry gate that assigns spots, a payment service that charges the driver, a database that tracks which spots are free. Nobody is writing a class yet - the concern is which piece of the system owns which job.

System design: which pieces exist, and who talks to whom.

LLD is what happens once you commit to building the "assign a spot" piece. Now the question is concrete: is there a Ticket class? What does it know? Does a SpotManager own the list of spots, or does ParkingSpot track its own state? Which object is responsible for picking a spot when a car pulls in?

associationaggregation

Low-level design: the classes, their fields, and how they collaborate.

Both diagrams describe the same parking lot. The first tells you almost nothing about how a spot actually gets assigned; the second is precise enough to hand to someone and have them write working code from it. That precision - naming the classes, their state, and their methods - is what "low-level" refers to. It is not a judgment about how important the work is, just about how close to the code the design has moved.

Try it yourself: pick a small system that is not a parking lot - a vending machine, a library checkout desk, a food-delivery order tracker. Sketch its LLD altitude: what two or three classes would you introduce, and what does each one actually hold and do?

Why interviewers care

A system-design answer can hide a lot of hand-waving behind a service boundary - "the matching service handles that" closes off the question without proving you could actually build it. LLD removes the hiding place. You have to say what the Ticket class actually holds, decide whether fee calculation belongs to Ticket or to a separate PricingStrategy, and defend why. It is a more direct test of whether you can turn a fuzzy requirement into a structure that a team could extend six months later without rewriting it.