Introduction

A system is never designed with unlimited time, money, computing resources, technology choices or operational freedom. Every real-world architecture must operate within boundaries known as constraints.

A constraint is a confirmed restriction or condition that the design must respect. Constraints narrow the available solution space and influence decisions involving:

• Architecture style
• Technology selection
• Cloud regions
• Data placement
• Integration methods
• Deployment strategies
• Security controls
• Operating cost
• Delivery scope
• Migration approach

In the System Design curriculum, constraints appear as Topic 1.3 under System Design Process and Estimation, after requirements discovery and functional versus non-functional requirements. The module establishes requirements, constraints, request flow and scale estimates before selecting architecture components.

Prerequisites

What Is a System Design Constraint?

A system design constraint is a confirmed limitation, mandatory condition or fixed boundary that restricts how a system may be designed, implemented, deployed or operated.

Constraint Template

Constraint ID:
CON-<number>

Category:
<Technical, business, regulatory, operational or another category>

Statement:
The solution must <specific mandatory condition>.

Source:
<Policy, stakeholder, contract, existing system or regulation>

Reason:
<Why the constraint exists>

Architecture impact:
<Decisions or components affected>

Verification:
<Review, test, audit or approval used to verify compliance>

Owner:
<Role accountable for clarification and approval>

Status:
Proposed / Confirmed / Changed / Retired

Requirement vs Constraint

Constraint vs Assumption vs Dependency

Categories of System Design Constraints

Technical Constraints

Technical constraints restrict technologies, protocols, platforms, interfaces or runtime environments.

Examples include:

• The application must integrate with an existing identity provider.
• The system must preserve compatibility with an existing API version.
• The service must run on an approved operating platform.
• An existing database schema cannot be changed during the first release.
• External integrations support only a particular protocol.
• A legacy client cannot send newly introduced fields.

Financial Constraints

Financial constraints establish limits for development, infrastructure, licensing, maintenance or per-operation cost.

• Monthly infrastructure cost must remain within an approved budget.
• The solution must avoid a licensing model prohibited by procurement.
• The first release must reuse an existing platform where practical.
• Data retention cost must remain within the approved operating model.

Regulatory and Legal Constraints

Regulatory constraints result from laws, contractual obligations, industry rules or internal governance policies.

• Specified data must remain in an approved geographic region.
• Personal data must be deleted according to an approved retention rule.
• Selected actions must produce an audit trail.
• Access to sensitive information must follow approved authorization rules.
• Third-party components must use acceptable licenses.

Organizational Constraints

Organizational constraints arise from internal standards, team structure, available expertise, ownership boundaries and support responsibilities.

• Only approved technologies may be used in production.
• The operations team supports a defined monitoring platform.
• The owning team has limited experience with a proposed technology.
• Different business units own separate source systems.
• A release requires architecture or security approval.

Operational Constraints

Operational constraints limit how the system may be deployed, monitored, maintained, recovered or supported.

• Deployment is permitted only during an approved release window.
• The service must integrate with the existing incident-management process.
• The application must expose health information required by the platform.
• Rollback must use the approved deployment mechanism.
• Production access is restricted to authorized support roles.

Schedule Constraints

Schedule constraints restrict delivery sequencing, migration timing or availability of related platforms.

• The first release must be ready before an existing platform is retired.
• A dependent API will become available only after a scheduled release.
• Data migration must occur within an approved maintenance window.
• Only the must-have scope can be delivered in the initial phase.

Compatibility Constraints

Compatibility constraints require the new design to continue working with existing clients, services, data formats or workflows.

• Existing API clients must continue working during migration.
• Previously created links must remain valid.
• The system must read an existing file format.
• Events must preserve fields used by current consumers.
• Database changes must support a staged deployment.

Security Constraints

Security constraints can prescribe mandatory controls or restrict data and access patterns.

• Secrets must be stored through the approved secret-management service.
• Administrative operations require strong authentication.
• Public clients cannot connect directly to the database.
• Sensitive fields cannot appear in application logs.
• External requests must pass through approved edge controls.

Data Constraints

Data constraints define limits involving ownership, quality, location, format, retention or migration.

• A source system remains the authoritative owner of customer data.
• Records must preserve existing business identifiers.
• Historical data cannot be corrected automatically.
• Some fields may be retained only for a defined period.
• Data from separate regions cannot be combined in one physical store.

Discovering Constraints

Constraints may not be stated directly during the first requirements discussion. The system designer must investigate the existing environment, internal standards and external obligations.

Stakeholder Questions

• Which technologies or platforms are mandatory?
• Which technologies are prohibited?
• Which existing systems must remain compatible?
• Who owns each source of data?
• Are geographic data restrictions applicable?
• Which security and audit controls are mandatory?
• What budget limits apply?
• Which release or migration deadlines are fixed?
• What can the operations team support?
• Which external-provider limits affect the design?
• Which decisions require governance approval?
• What happens if a documented constraint cannot be satisfied?

Constraint Sources

Worked Example: URL Shortener Constraints

Consider a URL shortener that must integrate with an existing enterprise environment.

Detailed Constraint Record

Constraint ID:
CON-02

Category:
Compatibility and migration

Statement:
Previously issued short codes must continue redirecting throughout migration.

Source:
Existing-system migration requirement

Reason:
Existing short links have already been distributed to users and external
channels.

Architecture impact:
The design must preserve existing identifiers, migrate mappings safely or
provide a compatibility lookup path.

Verification:
Execute redirect tests using representative existing short codes before,
during and after migration.

Owner:
Migration owner

Status:
Confirmed

How Constraints Affect Architecture

Classify Constraint Strength

Not every apparent constraint is equally fixed. Classifying its strength prevents preferences from being treated as mandatory rules.

Preference vs Real Constraint

The system must use Kafka because Kafka is the standard choice for events.

The solution must publish order events through the approved enterprise event
platform because existing consumers and operational controls depend on that
platform.

The improved statement identifies the existing dependency and explains why the restriction matters.

Constraint Register

Conflicting Constraints

Constraints may conflict with one another or with non-functional requirements.

Example Conflict

Requirement:
Provide very low redirect latency for global users.

Constraint:
All link data must remain in one approved region.

Conflict:
Global users may experience longer network latency when every read goes to one
region.

Resolution Process

1. Document the competing requirement and constraint.
2. Confirm the source and strength of the constraint.
3. Measure or estimate the user-visible impact.
4. Identify compliant design alternatives.
5. Compare correctness, cost, complexity and operational risk.
6. Escalate when no option satisfies both conditions.
7. Record the approved decision and accepted consequences.

Architecture Decision Record

Decision ID:
ADR-001

Title:
Redirect data placement under regional restrictions

Context:
Global redirect latency is important, but selected mapping data must remain in
an approved region.

Constraints:
CON-04 - Regional data placement

Options:
1. Serve every redirect from the approved region.
2. Cache only permitted derived data outside the region.
3. Use regional routing without replicating restricted fields.

Decision:
<Approved option>

Consequences:
<Latency, availability, cost, complexity and operational effects>

Verification:
<Compliance review, performance test and failure test>

Validating Constraints

A constraint must be verified against its source. A statement repeated during meetings is not automatically a confirmed constraint.

Common Constraint Mistakes

Constraint Review Checklist

Practice Exercise

Identify constraints for a notification platform that sends email, SMS and mobile push notifications.

Scenario

The organization already has approved email and SMS providers.
Mobile applications use an existing push-notification platform.
Personal recipient information must follow approved regional data rules.
The operations team uses an established monitoring platform.
The initial release has a controlled operating budget.
Existing applications must continue using the current notification API during
migration.

Model Classification

Your Tasks

1. Create a constraint register for the scenario.
2. Classify each constraint as hard, policy-based or negotiable.
3. Identify the source and owner of each constraint.
4. List three assumptions that require validation.
5. Identify two potential constraint conflicts.
6. Compare at least two architecture options for one conflict.
7. Write an architecture decision record for the selected option.

Frequently Asked Questions