Common LLD Interview Problems

The difference between a candidate who struggles with novel LLD problems and one who navigates them confidently often comes down to a single skill: pattern recognition. Experienced engineers don't see each problem as unique—they see it as an instance of a familiar category with known solution approaches.

When you encounter a new LLD problem, the wrong approach is to start from scratch, laboriously identifying entities and relationships as if you've never designed anything before. The right approach is to ask: 'What category does this problem belong to? What patterns have worked for similar problems?'

This mental categorization happens in seconds for experienced designers. The good news: it's a teachable skill. This page provides the taxonomy.

LLD problems can be organized into a small number of fundamental categories. Each category shares structural similarities, common entities, recurring relationships, and applicable design patterns. Once you recognize a problem's category, you instantly gain access to a solution template refined through dozens of similar problems.

The seven fundamental LLD problem categories:

Why categories matter:

Each category implies a set of design decisions:

• Dominant entities — Resource systems have Resources and Allocators; Game systems have Boards, Players, and Moves; Matching systems have Suppliers, Consumers, and Matches.

• Core patterns — Resource systems favor State and Strategy; Games favor Command and Memento; Matching systems favor Strategy and Observer.

• Primary challenges — Resource systems grapple with concurrency; Games with rule validation; Transaction systems with atomicity; Matching systems with algorithm design.

Understanding the category immediately narrows your design space to proven solutions.

Resource Management systems are perhaps the most common LLD problem category. They involve allocating finite resources to consumers while managing lifecycle, availability, and pricing. The Parking Lot system—the quintessential LLD problem—belongs to this category.

Signature design elements:

1. Resource Hierarchy: Resource management problems often have multiple resource types with a common interface:

class Resource (abstract)
├── ParkingSpot → CompactSpot, RegularSpot, LargeSpot
├── HotelRoom → StandardRoom, SuiteRoom, DeluxeRoom  
├── Seat → RegularSeat, PremiumSeat, VIPSeat

2. Allocation Lifecycle: The allocation entity (Ticket, Reservation) tracks the relationship between resource and consumer over time. It captures timestamps, pricing, and status.

3. Availability Queries: A critical operation is determining available resources that match criteria. This often requires efficient data structures (maps, trees) and careful handling of date/time ranges.

4. Pricing Strategies: Almost all resource systems involve pricing. The Strategy pattern naturally applies—hourly pricing, flat rate, dynamic pricing, member discounts.

5. Capacity Constraints: The manager tracks total capacity, current utilization, and enforces limits. Capacity checks must be atomic to prevent over-allocation.

Game systems are LLD favorites because they combine clear rules with rich state management. Every move must be validated, game state must be tracked, and win/loss conditions must be detected. These problems provide excellent playgrounds for the State, Command, and Strategy patterns.

Signature design elements:

1. The Move Abstraction: In game systems, actions are modeled as first-class objects. This enables undo/redo (Memento pattern), replay (storing move history), and validation (each move knows how to check its legality).

class Move
├── sourcePosition
├── targetPosition  
├── player
├── timestamp
├── execute(board) → applies the move
├── validate(board) → checks legality
├── undo(board) → reverses the move

2. Piece Hierarchies: Games with different piece types naturally use polymorphism. Chess is the canonical example—each piece type has a unique movement pattern but shares a common interface.

3. Rules Engine: Complex games benefit from extracting validation logic into a separate Rules Engine class. This keeps the game controller clean and makes rule variations easy to implement.

4. Turn Management: Whose turn is it? How do turns progress? In simple games, this is trivial; in complex games (multi-phase turns, interrupts), it becomes a significant subsystem.

5. Win/Draw Detection: The game must detect when it ends. For simple games, this is straightforward; for Chess (checkmate, stalemate, draw by repetition), it requires sophisticated logic.

Transaction systems model multi-step processes where each step modifies system state and the overall process must be tracked from start to completion. ATM transactions, order processing, and loan applications all belong to this category. The defining characteristic is a workflow with explicit states and transitions.

Signature design elements:

1. State Machine Core: Transaction systems are fundamentally state machines. Every transaction has a current state, and only specific transitions are valid from each state.

Transaction States:
┌─────────────────────────────────────────────────────────────┐
│  CREATED → VALIDATED → PROCESSING → COMPLETED              │
│     ↓          ↓            ↓                               │
│  CANCELLED   REJECTED     FAILED → RETRY → PROCESSING      │
└─────────────────────────────────────────────────────────────┘

2. The Processing Pipeline: Complex transactions often involve multiple validation and processing steps. Chain of Responsibility allows steps to be added, removed, or reordered without changing the core transaction logic.

3. Ledger/Audit Trail: Transaction systems require immutable records of what happened. Every state change, every validation result, every retry attempt must be logged for compliance and debugging.

4. Error Handling Strategy: What happens when step 3 of 5 fails? Transaction systems need clear policies: full rollback, partial completion, retry with backoff, manual intervention.

5. Idempotency: Retrying a transaction shouldn't create duplicate effects. Idempotency keys and deduplication logic are essential for reliable transaction systems.

Matching systems connect suppliers (drivers, restaurants, workers) with consumers (riders, customers, tasks) based on constraints and optimization criteria. Uber, DoorDash, and TaskRabbit are real-world examples. These systems are algorithmically rich, requiring both solid OOP design and matching algorithm sophistication.

Signature design elements:

1. The Matching Engine: The heart of these systems is an engine that takes a request and finds the best supplier. This is typically modeled as a Strategy pattern with pluggable matching algorithms:

interface MatchingStrategy {
    findMatch(request: RideRequest, availableDrivers: Driver[]): Match | null
}

class NearestDriverStrategy implements MatchingStrategy { ... }
class HighestRatedDriverStrategy implements MatchingStrategy { ... }
class OptimalETAStrategy implements MatchingStrategy { ... }

2. Location Tracking: Matching systems are inherently spatial. Suppliers have current locations; requests have pickup/delivery locations. Efficient spatial indexing (in production: geohashing, R-trees) enables fast proximity queries.

3. Real-Time State Updates: Supplier availability changes constantly. Consumers need status updates. Observer pattern or event-driven architecture enables decoupled, real-time communication.

4. Multi-Stage Lifecycle: A ride request goes through Requested → Searching → Matched → Pickup → In Transit → Completed (or Cancelled at various points). Each stage has different behaviors and valid transitions.

5. Timeout and Fallback: What if no supplier accepts? Matching systems need timeout policies, re-matching logic, and graceful degradation (expand search radius, reduce criteria).

Content systems manage collections of items with rich metadata, hierarchical organization, search/discovery, and access control. Libraries, e-commerce catalogs, and media streaming platforms are examples. These problems emphasize data modeling, relationship design, and query patterns.

Signature design elements:

1. Item Hierarchies: Content often has variations (Book → Physical, eBook, Audiobook; Product → with color, size variants). This maps naturally to inheritance or composition with a Variant pattern.

2. Category Structure: Categories form trees (or directed acyclic graphs). The Composite pattern elegantly represents categories that contain both subcategories and items.

3. Rich Metadata: Content items have extensive metadata: descriptions, images, specifications, tags, ratings. Consider whether metadata is intrinsic to the item or contextual (e.g., a book's description vs its current price at a retailer).

4. User Interactions: Users interact with content: viewing, purchasing, rating, saving. These interactions are first-class entities, not just method calls, because they're needed for history, recommendations, and analytics.

5. Search & Discovery: How do users find items? Browsing categories, keyword search, recommendations. LLD doesn't require implementing search engines, but your design should accommodate search as a first-class operation.

Social systems model user relationships, content sharing, and real-time interactions. They're characterized by complex relationship graphs, event-driven notifications, and activities that span multiple users. Twitter, Stack Overflow, and Slack are canonical examples.

Signature design elements:

1. The Relationship Graph: User connections are the foundation. Model relationship types (follow vs friend vs block), directionality (asymmetric follow vs symmetric friend), and relationship metadata (connection date, strength).

2. Content Hierarchies: Social content is often threaded: posts have comments, comments have replies, messages form conversations. The Composite pattern handles this recursion.

3. Feed Generation: How is a user's feed populated? Common approaches:

• Pull: Query all followed users' content on demand (simple, expensive)
• Push: When user posts, fan-out to followers' feeds (complex, fast reads)
• Hybrid: Push to active users, pull for others

4. Notification System: Events (mentions, likes, replies) trigger notifications. The Observer pattern decouples content creation from notification dispatch, making the system extensible.

5. Privacy & Visibility: Social content has visibility rules: public, friends-only, private. Every content query must respect these rules. Model visibility as a first-class concern, not an afterthought.

Infrastructure systems model technical components rather than business domains. Rate limiters, caches, message queues, and schedulers are examples. These problems test understanding of system internals and are increasingly common at senior levels where candidates are expected to design foundational components.

Signature design elements:

1. Algorithm-First Design: Infrastructure problems often have the algorithm as the core. A rate limiter IS a token bucket or sliding window algorithm wrapped in an object. The OOP design serves the algorithm, not the other way around.

2. Performance Constraints: Infrastructure operates on every request. Operations must be O(1) or near-constant. Data structures are chosen for performance: hash maps, circular buffers, skip lists.

3. Thread Safety: Infrastructure is inherently concurrent. Every design decision must consider thread safety: atomic operations, locks, lock-free structures, or explicit serialization.

4. Configuration & Policies: Infrastructure is configurable. Limits, thresholds, algorithms, and behaviors are parameters, not constants. The Strategy pattern naturally represents pluggable policies.

5. Observability Built-In: Infrastructure must be observable. Metrics (request count, hit rate, queue depth), logging, and health checks are design requirements, not afterthoughts.

While problems fit into categories, certain design challenges and patterns cut across all categories. Recognizing these cross-cutting concerns accelerates design regardless of the specific problem.

Recognition triggers:

Train yourself to recognize pattern opportunities from problem descriptions:

• 'The pricing/matching/routing can vary by...' → Strategy pattern
• 'When something happens, we need to notify/update...' → Observer pattern
• 'Users can undo/replay/audit actions...' → Command pattern
• 'The entity goes through stages/phases...' → State pattern
• 'Items are organized hierarchically...' → Composite pattern
• 'Create different types of X based on...' → Factory pattern

These triggers work across problem categories. The Strategy pattern for pricing in a Parking Lot is structurally identical to the Strategy pattern for matching in Uber—the domain differs, the pattern is the same.

You now possess a systematic framework for categorizing LLD problems. This framework transforms your approach from problem-by-problem memorization to pattern-based reasoning.

What's next:

Now that you can categorize problems and recognize patterns, the next page provides a concrete practice problem list. You'll see exactly which problems to practice, in what order, and how to structure your preparation for maximum efficiency.