How to approach a low-level design problem

Low-level design is about structure

A high-level design decides servers, databases and queues. A low-level design (LLD) decides classes, methods and relationships inside one program. The questions are: what objects exist, who owns which rule, and how will this change next month?

Interviewers use LLD problems (a parking lot, an elevator, a chess game) because a small problem shows how you think: do you clarify, do you model sensibly, do you keep rules in one place, do you notice concurrency?

The six steps

100%

Figure SDA-LLD-01-1 · The six-step method for low-level design · © forcsguy.com

1. Clarify requirements. Who uses it? What are the three to five main flows? What is the scale? What is deliberately out of scope?
2. Find the nouns and verbs. Nouns become candidate classes; verbs become methods. Drop nouns that are only values (a price can be a number or a small value type).
3. Assign responsibilities. Each class owns its data and the rules about that data. If a rule needs data from two classes, ask which one should own it or whether a third coordinating class is justified.
4. Draw relationships. Has-a (composition), is-a (inheritance, used sparingly), uses (dependency). Prefer composition and interfaces to deep inheritance.
5. Apply patterns where they earn their keep. A lifecycle with many states suggests the State pattern; swappable rules (pricing, matching) suggest Strategy; things that react to events suggest Observer; complex creation suggests Factory.
6. Code the core flow, then stress it. Write the happy path, then ask: what if two users act at once? What if the input is invalid? What if a step fails halfway?

Habits that earn trust

• Names carry meaning. ParkingSpot, Ticket, calculateFee beat Manager and process.
• Single responsibility. A class that "does everything" is the usual red flag.
• Depend on interfaces at the points that will change (payment method, pricing rule), not everywhere.
• Make illegal states hard to represent. Use enums or state objects instead of loose strings and booleans.
• Say your trade-offs aloud. "I used a simple map here; if we needed millions of spots I would index by level."

A tiny example of the method

Requirement: "a vending machine that sells snacks for coins". Nouns: machine, product, slot, coin. Verbs: select, insert, dispense, refund. Responsibilities: Inventory knows what is in each slot; VendingMachine coordinates the flow; a state (idle, has money, dispensing) decides which actions are allowed. Only the state and the stock rules need real design; the rest is plain code.

The following lessons apply this method to well-known problems. Each ends with the extensions an interviewer is likely to ask for.

Real-world reading