Every LLD problem exists within a boundary. Understanding where that boundary lies—what's in scope and what isn't—is one of the most consequential decisions you'll make. Get it wrong, and you'll either design a system that's woefully incomplete or one that's overengineered beyond recognition.

The scope paradox:

In an interview, you have 45-60 minutes. You cannot design an entire e-commerce platform with inventory management, payment processing, recommendation engines, and fraud detection. Yet the problem statement may imply all of these. Your task is to identify the core scope that can be meaningfully designed in the available time while still demonstrating competence.

In real projects, the challenge is different but related: requirements documents often contain mountains of features. Your task is to identify what must be built now versus later, what the technical constraints permit, and how to create extensible designs that accommodate future scope.

Constraints are your friends:

Many engineers view constraints negatively—limitations on their creativity. In reality, constraints are design guides. They eliminate possibilities, reducing the solution space to something manageable. A system that must handle 'millions of users' demands different design choices than one for 'a single office.' A system with 'real-time' requirements differs from one with 'eventual consistency is acceptable.' These constraints don't limit you—they direct you.

Scope defines the boundaries of what your design will address. It answers the fundamental question: What problem are we solving, and what problems are we explicitly NOT solving?

In LLD specifically, scope operates at multiple levels:

The scoping spectrum:

Every LLD exercise falls somewhere on a spectrum from 'tightly scoped' to 'open-ended':

Tightly Scoped Problems:

• 'Design the class structure for a vending machine'
• Clear boundary: the vending machine itself
• What's out: inventory management systems, payment gateway internals

Moderately Scoped Problems:

• 'Design a parking lot management system'
• Boundary to determine: Do we include payment? Multi-location? Reservations?
• Requires clarifying questions

Open-Ended Problems:

• 'Design the backend for Uber'
• Massive scope requiring significant pruning
• Must actively reduce to something designable in time

Your first task is determining where on this spectrum your problem lies.

Constraints are the guardrails of your design. They come in several flavors, and missing any type leads to flawed designs.

Explicit Constraints:

These are directly stated in the problem. They're often numerical and precise:

• 'A member can borrow up to 5 books'
• 'The system should handle 10,000 concurrent users'
• 'Parking spots come in three sizes: small, medium, large'

Explicit constraints are relatively easy to handle—they're in the text, waiting to be extracted.

Implicit Constraints:

These are assumed based on domain knowledge or common sense:

• A user can't borrow a book that's already borrowed (obvious, but rarely stated)
• Time moves forward (a book can't be returned before it's borrowed)
• Money doesn't magically appear (payments must balance)

Domain Constraints:

These come from the problem domain itself:

• Library systems: ISBN format, catalog classifications
• Financial systems: Transaction atomicity, audit requirements
• Gaming systems: Fair play, latency expectations

Technical Constraints:

These arise from the implementation environment:

• Must integrate with existing authentication system
• Must work with relational database
• Must be stateless for horizontal scaling

Use a systematic framework to define scope explicitly. This ensures nothing is missed and creates a shared understanding with stakeholders (or interviewers).

The In/Out/Later Framework:

For every feature or capability mentioned or implied, categorize it:

Example: Library Management System

Let's apply this to our running example:

Use a constraint extraction checklist to ensure you've captured all relevant constraints from the problem statement.

The Constraint Elicitation Checklist:

Applying the Checklist:

Let's apply each category to our library example:

One of the most nuanced aspects of scoping is distinguishing between what's explicitly in scope, what's implicitly expected, and what's genuinely out of scope.

Explicit Scope:

Directly stated in the problem. No ambiguity.

• 'Design a system for borrowing and returning books' → Borrowing/returning is definitely in scope
• 'Calculate fines for overdue books' → Fine calculation is definitely in scope

Implicit Scope:

Not stated, but any reasonable design would include it. Domain knowledge tells you it's necessary.

• Problem mentions 'borrow books' but not 'return books' → Returning is implicitly in scope
• Problem mentions 'members' → Member registration is probably implicitly expected
• Problem mentions 'availability' → Checking available copies before borrowing is implicit

Gray Zone:

Features that reasonable engineers might disagree about. This is where you either ask or explicitly state your assumption.

• 'Book search' is mentioned → Is fuzzy search expected? Autocomplete?
• 'Members can borrow' → Can members have different tiers with different limits?
• 'Fine calculation' → Is payment processing in scope?

The Assumption Declaration:

For gray zone items, explicitly state your assumption:

'The problem doesn't mention payment processing for fines. I'll assume fine collection is handled externally, and our system just tracks fine amounts owed. Is that acceptable, or should I include payment?'

This does three things:

1. Shows you identified the ambiguity (thoroughness)
2. Gives a reasonable default (decisiveness)
3. Invites correction (communication)

Interviewers (and stakeholders) appreciate this pattern. It's exactly how senior engineers handle ambiguity in real projects.

In interviews, time-boxing forces hard scope decisions. Here are strategies that work:

Strategy 1: MVP-First Scoping

Identify the Minimum Viable Product—the smallest set of features that makes the system coherent:

• What's the core value proposition?
• What single use case, if perfectly designed, would show competence?
• What can be deferred to 'future enhancements'?

Strategy 2: Depth Over Breadth

It's better to deeply design 3 entities than shallowly sketch 10. Interviewers evaluate:

• Quality of class design
• Relationship modeling
• Pattern application
• SOLID adherence

None of these can be demonstrated in a shallow sketch.

Strategy 3: Explicit Time Allocation

Verbally scope based on time:

'Given 45 minutes, I'll focus on the core booking flow, including User, Ride, Driver, and Matching logic. I'll defer payment, ratings, and real-time tracking to extensions. Does that work?'

This shows awareness of constraints and reasonable prioritization.

Strategy 4: Scope Negotiation as Skill Demonstration

Scoping well demonstrates the exact skills companies want:

• Prioritization — You can identify what matters most
• Communication — You can articulate scope clearly
• Pragmatism — You balance ambition with reality
• Stakeholder Management — You seek alignment, not unilateral decisions

Don't view scoping as a necessary evil before the 'real' design work. It IS part of the design work, and you're being evaluated on it.

Constraints aren't just limitations—they're signposts pointing toward the right design. Each constraint suggests specific design decisions.

Constraint-Driven Design Decisions:

The Constraint-to-Pattern Mapping:

Experienced engineers develop intuition for which patterns address which constraints:

Cardinality Constraints → Aggregate Roots When one entity 'controls' the count of another (parent controls how many children), the parent becomes an aggregate root managing that invariant.

Variability Constraints → Strategy/Factory When 'different types need different behavior' (pricing, validation, processing), the Strategy pattern allows runtime flexibility.

State Constraints → State Pattern/Enum When entities have explicit states with controlled transitions, either a formal State pattern or a well-managed enum is appropriate.

Temporal Constraints → Temporal Modeling When 'when' matters (effective dates, history), entities need timestamps, date ranges, or full temporal modeling.

Concurrency Constraints → Locking/Events When 'only one can succeed' (booking last seat), optimistic locking, pessimistic locking, or event-driven designs address the race condition.

Scope decisions made but not documented are scope decisions waiting to be forgotten. Use structured documentation to capture and communicate scope.

The Scope Decision Record:

For each significant scope decision, document:

1. The decision — What's in/out of scope?
2. The rationale — Why this boundary?
3. The implications — What does this mean for the design?
4. The alternatives — What else was considered?
5. The reversibility — How hard to change later?

Why Documentation Matters:

1. Prevents Drift — Halfway through design, you might unconsciously start adding out-of-scope features. The document refocuses you.

2. Enables Review — Others (interviewers, teammates) can evaluate whether scope decisions were reasonable.

3. Captures Rationale — Six months later, when someone asks 'why didn't we include X?', the answer is documented.

4. Shows Professionalism — Engineers who document scope demonstrate senior-level practice.

In Interviews:

You won't write formal documents, but you should verbally state and possibly whiteboard your scope boundaries before diving into class design. This serves the same purpose: clarity, agreement, and reference.

Identifying scope and constraints is the bridge between understanding the problem and designing the solution. Let's consolidate the key principles:

What's Next:

With scope and constraints identified, the next page addresses Clarifying Ambiguities—how to identify what's unclear, formulate clarifying questions, and systematically reduce uncertainty before design begins.