Requirements to Constraints
Turning stated requirements into the constraints that actually bound a design.
4 to work through
-
beginner
A live-sport streaming service is planning for a cricket final. Marketing says "be ready for a big audience". The semi-final peaked at 1.8 million concurrent viewers and climbed from 400000 to 1.8 million in roughly 90 seconds at the first ball. Segments are 4 seconds long. Roughly what does the final demand, and which of those numbers actually constrains the design?
3 min answer -
intermediate Multiple choice
A video conferencing product grows from 10 million to 300 million daily participants in ten weeks. No feature request changed. Which part of the architecture is under threat first, and why?
2 min answer -
intermediate
Groww's brokers and exchanges are only reachable during market hours, settlement files arrive at fixed times, and regulators require an immutable audit record. Which of these is a requirement and which is a constraint, and why does the distinction matter?
1 min answer -
advanced
A short-video recommendation service was designed when a median session pulled 20 videos and feature computation took 40 ms. Two years later sessions pull 200 videos, the model is larger, and p99 recommendation latency has quietly tripled - yet no single change looks responsible. How do you diagnose this as a constraints problem rather than a code problem?
2 min answer
3 terms in this topic
Constraint Discovery
The systematic elicitation of the fixed conditions a solution must satisfy, distinguished from requirements because they are not negotiable and are r…
practiceConstraint Expiry
Recording every constraint with its source and its expiry date, so that temporary facts do not get permanently encoded into an architecture.
practiceRequirements to Constraints
The translation step where a stated business wish becomes a number that rules designs out.
Neighbouring topics
Architecture Fundamentals
General material on what solution architecture is and what an architect is accountable for.
Functional vs Non-Functional
Behaviour versus quality of behaviour, and why only the second constrains structure.
Architectural Drivers
The small subset of requirements whose change would force the structure to change.
Quality Attributes
Availability, latency, throughput, security, cost — expressed as testable scenarios.
Architecture Principles
Durable agreed rules that rule options out, stated with rationale and implications.
Coupling
How much one component must know about, or change alongside, another.
Cohesion
Whether the things inside a boundary belong together and change for the same reason.
Modularity
Composing a system from parts that can be understood and replaced independently.
Separation of Concerns
Organising so that a change to one concern touches one place.
Abstraction & Encapsulation
Hiding mechanism behind contract, and protecting invariants by owning state.
Architecture Styles
System-level organising shapes, and how they differ from problem-level patterns.
Evolutionary Architecture
Designing for guided incremental change rather than for correctness on day one.
Fitness Functions
Automated checks that an architectural characteristic still holds.
Architecture Documentation
What to write down, at what altitude, and what nobody will ever read.
Conway's Law
Systems mirroring the communication structure of the organisation that builds them.
Trade-off Fundamentals
Why every architecture is a set of purchases, and how to state what you gave up.
Technical Constraints
Existing estate, skills, licences and platforms as inputs rather than obstacles.
Architecture Roles
Solution, enterprise, domain and platform architecture, and where each is accountable.
Reference Models
Shared conceptual frames — layering, tiers, viewpoints — and their limits.