The Four Types of LLD Problems
Every LLD interview prompt falls into one of four archetypes. Identifying the archetype early tells you which entities to look for, what state matters, and where the tricky edge cases will land. Before writing any classes, naming the archetype out loud — "this is a data-management system" or "this is a utility" — shapes every design decision that follows.
| Archetype | What it models | Example problems | The real design pressure |
|---|---|---|---|
| Data-management system | Users creating, querying, and relating records under business rules | Library, gym membership, expense splitter | Rule enforcement — keep each rule with the entity that owns the state |
| Game / simulation | A closed world with explicit rules and a turn loop | Tic-Tac-Toe, Chess, Snake & Ladder | Keep game rules in the board/rules class, apart from input and display |
| Utility | A reusable infrastructure component with a tight interface | LRU cache, logger, rate limiter | Correctness and efficiency — pick the data structure that meets the contract |
| Real-world entity | A physical device or facility with hardware-like parts | Parking lot, elevator, ATM, vending machine | State management — model the state machine before the classes |
Data-Management Systems
A data-management problem asks you to model a domain where users create, update, and query records — and where those records have relationships and business rules governing them. A library management system, a gym membership tracker, and a bill-splitting app are all variations of the same shape: there are members, there are resources, and there are rules about who can do what with which resource.
Data-management problems mainly test rule enforcement around domain entities. A library book can be borrowed only if it is available. An expense can be settled only if every participant has been charged. The design must embed those rules with the entity that owns the state, so no caller can violate them by accident.
These problems are recognizable when the prompt involves users, resources, and transactions
between them. Words like "book," "reserve," "cancel," "settle," "member," or "plan" are strong
signals. There is almost always a many-to-many relationship that needs an intermediary class (a
Loan between Member and Book, a Split between Expense and User).
Approach data-management problems by identifying the resource, the actor, and the transaction that links them. Model the transaction as a first-class entity with its own state, rather than a flag on the resource.
Games and Simulations
A game or simulation problem gives you a closed world with explicit rules and asks you to model the mechanics. Tic-tac-toe, chess, and Snake & Ladder share the same skeleton: a board, a set of players, a turn loop, and win/draw detection. The code must enforce the rules of the game — not invent them.
The design pressure here is different from data-management. The board is the source of truth for what is legal. A move is valid or not based on the board state, and the class that owns the board state is the one that decides — not the player, and not the controller. Separating the game rules from the display logic and from the player-input loop is the main design skill these problems test.
These problems are recognizable when the prompt names a game or says "simulate." There are clearly defined players (two or more), a board or arena, and a sequence of turns. The problem will ask about win/draw conditions and how to extend the game (e.g. from two players to four, or from a 3×3 board to an N×N board).
Approach game problems by identifying the board, the move, the player, and the game controller. Keep game-rule logic inside the board or a dedicated rules class, not scattered across player methods. Parameterize dimensions and player counts from the start — interviewers almost always ask you to generalize.
Utilities
A utility problem asks you to implement a reusable infrastructure component: an LRU cache, a rate limiter, a logger, a pub-sub event bus. These problems are narrower in scope than data-management systems but demand more precision. Every method must have a clearly specified contract, and the implementation must handle the edge cases that distinguish a toy from a production component.
The design pressure is correctness and efficiency. An LRU cache that is correct but evicts in O(n) time will draw a follow-up. A rate limiter that does not handle burst traffic is incomplete. The interviewer is testing whether you can reason about data structure choices — not just whether you can name the right one.
These problems are recognizable when the prompt names a component found in an infrastructure layer, not a business domain. The problem is self-contained — no users, no accounts, no reservations. There is usually a tight interface: two or three methods, with edge cases in the boundary conditions.
Approach utility problems by specifying the interface contract first, then reasoning aloud about which internal data structure satisfies the time complexity requirements. State the trade-offs explicitly — an interviewer asking about a logger wants to hear the difference between sync and async writes before they ask about it.
Real-World Entity Systems
A real-world entity problem asks you to model a physical system with concrete hardware components: a parking lot, an elevator bank, an ATM, a vending machine. The entities are usually obvious from the prompt — floors, cars, buttons, cash trays — but the design still has to model the state-machine logic underneath.
The design pressure is state management. An elevator's design centers on its states (idle, moving up, moving down, doors open) and the order it serves requests; an ATM's centers on guarding each transition through its authentication and dispensing states. The physical object is a hint about what states exist; the state machine is the actual design problem.
These problems are recognizable when the prompt names a physical device or facility. There will
be multiple hardware-like components and a control loop. Concurrency is frequently a follow-up
(two cars competing for the last spot, two people pressing the elevator button simultaneously),
so these problems are often tagged concurrency: true in the course.
Approach real-world entity problems by mapping the state machine for the primary entity before sketching any classes. The states and transitions tell you what methods are needed, what invariants must hold, and where locking will be required. You will learn to draw state machines formally in Module 2; for now it is enough to list the states the entity moves through and the events that carry it between them.
How the archetypes connect to the rest of the course
Every case study in this course is labeled with one of these four archetypes. When a walkthrough is tagged "data-management," the starting point is to locate the resource, the actor, and the transaction. When it is tagged "real-world entity," the starting point is the state machine. The taxonomy guides which clarifying questions to ask and which design moves to reach for first.
The next article introduces the six-step delivery framework that each case study follows, regardless of archetype.