With requirements read and understood, the next critical step is defining boundaries. Scope determines what you will build. Constraints determine how you can build it. Together, they transform an infinite possibility space into a tractable engineering problem.

Without clear scope, projects expand endlessly—the infamous 'scope creep' that destroys timelines and budgets. Without understood constraints, engineers propose solutions that cannot be implemented—technically infeasible, economically unviable, or politically impossible.

The ability to precisely define scope and constraints is what separates engineers who deliver from engineers who perpetually iterate. It's what distinguishes system designs that work from system designs that look good on a whiteboard but collapse under reality's weight.

Scope is the explicit boundary separating what your system is responsible for from what it is not. It answers the fundamental question: What exactly are we building?

This sounds obvious, but scope is deceptively complex. It operates at multiple levels simultaneously, and confusion at any level creates problems:

Levels of Scope:

1. Feature Scope: Which features are included in this system?
2. User Scope: Which users or user types does this system serve?
3. Data Scope: What data does this system own, and what data comes from elsewhere?
4. Responsibility Scope: What behaviors does this system guarantee, and what does it delegate?
5. Time Scope: What must be built now vs. what can wait?

Defining scope is not a single decision but a process. This process should be explicit and repeatable.

Step 1: List All Potential Features

From your requirement analysis, enumerate every feature that could be part of the system. Don't filter yet—capture everything. This becomes your scope universe.

Step 2: Categorize by Necessity

For each feature, assign it to one of four categories:

Step 3: Define Boundaries with Explicit Statements

Translate your categorization into explicit boundary statements. These statements form your scope contract:

✅ IN SCOPE
- The system WILL provide [feature A]
- The system WILL handle [use case B]
- The system WILL own [data C]

❌ OUT OF SCOPE  
- The system WILL NOT handle [feature X]
- The system WILL NOT be responsible for [behavior Y]
- The system WILL delegate [function Z] to [external system]

⏳ FUTURE SCOPE
- [Feature] is deferred to phase 2 because [reason]
- [Capability] requires [prerequisite] which isn't ready

Step 4: Validate Scope Coherence

Review your scope definition for internal consistency:

• Do the 'in scope' items form a coherent system?
• Are there dependencies between 'in scope' and 'out of scope' items?
• Is the scope achievable within stated constraints?
• Does it solve the core problem from requirements?

Step 5: Document Dependencies on Out-of-Scope Systems

For anything out of scope that your system depends on, document:

• What the external system provides
• What interface you expect
• What happens if that system fails or changes

While scope defines what you're building, constraints define the boundaries of how you can build it. Constraints are limitations you must work within—they're not negotiable without changing the fundamental problem.

The Four Constraint Categories:

Every system design operates under constraints from four distinct dimensions. Complete constraint identification requires examining all four:

Constraints are rarely handed to you on a silver platter. They must be systematically identified through probing questions and careful analysis. Here are proven techniques for surfacing constraints:

Probing Questions for Each Category:

Resources:

• What's our budget for this project?
• How many engineers can work on this, and for how long?
• What infrastructure is already provisioned?
• Is there budget for third-party services?

Absolutes:

• Are there any regulatory requirements?
• What SLAs are we contractually committed to?
• Are there hard deadlines that cannot move?
• What would cause this project to be considered a failure?

Precedents:

• What architectural patterns does the organization already use?
• Are there technology choices that are non-negotiable?
• Have similar systems been built before? What can we learn?
• What decisions have stakeholders already committed to?

Interfaces:

• What existing systems must this integrate with?
• What are those systems' APIs and SLAs?
• Who owns those systems, and what's our relationship?
• What happens if those systems are unavailable?

Dependencies:

• What other teams' work does this depend on?
• What external services are required?
• What's the reliability of those dependencies?
• Do we have fallback options if dependencies fail?

Not all constraints are equally binding. Understanding the difference between hard constraints and soft constraints enables smarter trade-off decisions.

Hard Constraints: Non-negotiable boundaries that cannot be violated under any circumstances.

• Physical laws (speed of light, disk I/O limits)
• Legal requirements (GDPR, PCI-DSS)
• Contractual obligations (SLAs, vendor agreements)
• Business existence criteria (system must work or company fails)

Characteristics of Hard Constraints:

• Violation means failure (legal, technical, or existential)
• Cannot be traded off against other factors
• Must be satisfied by any viable design

Soft Constraints: Preferences or targets that can be relaxed under the right circumstances.

• Performance targets ('we'd like p99 < 100ms, but 200ms is acceptable')
• Budget preferences ('ideally under $20K/month, but we can go to $30K if needed')
• Timeline preferences ('want Q1, but can slip to Q2 if necessary')
• Feature preferences ('nice to have analytics, but can launch without')

Characteristics of Soft Constraints:

• Violation is undesirable but not fatal
• Can be traded against other soft constraints
• Provide flexibility for optimization

The Constraint Negotiation Strategy:

1. Identify all constraints precisely — Document each constraint with its exact parameters
2. Classify as hard or soft — Determine what's truly non-negotiable
3. Rank soft constraints — Prioritize which soft constraints matter most when trade-offs are needed
4. Explore constraint relaxation — For soft constraints blocking a good solution, ask: 'What if we relaxed this?'
5. Document trade-offs explicitly — When relaxing constraints, document what was traded and why

Warning: Fake Hard Constraints

People often present soft constraints as hard ones. 'We must use MongoDB' might actually mean 'we're familiar with MongoDB.' 'This must be done by Q1' might mean 'we'd like Q1 but Q2 is actually possible.' Probe claimed hard constraints with: 'What happens if we can't meet this?' Truly hard constraints have severe, specific consequences.

Scope and constraints interact in fundamental ways. When constraints tighten, scope must often shrink. When scope expands, constraints become harder to meet. Understanding these trade-offs is critical to realistic design.

The Project Management Triangle Applied to System Design:

The classic project management 'iron triangle' has three vertices: Scope, Time, and Resources. You can optimize for any two, but the third suffers.

In system design, this expands to a multi-dimensional trade-off space:

The Scope-Time-Quality Trade-off in Practice:

Suppose you're designing a feed system with these initial parameters:

• Scope: Personalized, real-time feed for 10M users
• Time: 3 months to launch
• Quality: p99 latency < 100ms, 99.9% availability

Halfway through, business says: 'We actually need 50M users at launch.'

Something must give. Your options:

1. Extend Time: 3 months → 6 months for proper scaling design
2. Reduce Scope: Remove personalization initially, add later
3. Reduce Quality: Accept 500ms latency initially, optimize later
4. Add Resources: Double the team (if that's even effective)

There's no magic solution—each option has real costs. Your job is to present these trade-offs clearly to stakeholders, not to promise the impossible.

Scope and constraints must be documented explicitly. This documentation becomes your design contract—it's what you'll refer back to when questions arise, scope creep threatens, or stakeholders ask why something wasn't included.

The Scope and Constraints Document:

Why This Level of Documentation Matters:

1. Alignment: Everyone agrees on what's being built before building starts
2. Reference Point: When scope creep appears, you can point to the document
3. Decision Record: Trade-offs are documented with rationale, helping future teams
4. Risk Management: Dependencies and constraints are visible, enabling proactive management
5. Interview Success: In system design interviews, this level of clarity signals senior thinking

Let's apply scope and constraint definition to a real system design problem.

The Prompt:

Design a rate limiting service for a large API platform.

We've covered the essential skill of defining boundaries in system design. Let's consolidate the key takeaways:

What's Next:

With scope and constraints defined, ambiguities still remain. The next page explores how to clarify ambiguities—the systematic process of identifying unclear requirements, resolving them through targeted questioning, and documenting resolutions to prevent future confusion.