Constraints

A constraint is a fixed boundary on the solution that the design team cannot change by itself. It might be a mandated platform such as AWS only, a regulation such as RBI data localisation, a budget ceiling, a hard deadline like a Diwali sale, an existing system that must be integrated, or the size and skills of the available teams. The important point is that a constraint is imposed from outside the design: someone with authority set it, and changing it needs their agreement and usually a cost. Because constraints remove options rather than describe goals, identifying them early tells you which parts of the solution space are not worth exploring.

The usual categories are technical, regulatory, organisational, financial, time, integration and physical. Technical constraints include the mandated language, runtime, cloud and existing systems of record, such as Java 25 with Spring Boot 4 on EKS. Regulatory and legal ones cover data residency, PCI DSS, DPDP consent and retention rules. Organisational constraints are about team count, size, skills and structure, where Conway's law applies. Financial means run budgets and licence models; time means deadlines and change freezes. Integration covers partner protocols and legacy interfaces, such as a carrier that only sends SFTP files. Physical constraints include network latency between regions, device capability and bandwidth at branches.

A requirement is a goal the system should achieve, and the design is judged by how well it meets it; a constraint is a boundary the design must stay within, and it is either respected or broken. Requirements such as p99 latency under 300 milliseconds or 18,000 orders per second can be traded against each other and negotiated with stakeholders. A constraint such as customer data staying in India is not optimised at all: it simply removes options like replicating to Singapore. The distinction matters because teams waste effort trying to optimise constraints or, worse, treat negotiable requirements as fixed. A third category, assumptions, are beliefs that still need confirming.

Conway's law observes that organisations design systems that mirror their own communication structures. If three teams build a compiler, you get a three-pass compiler; if one integration team owns every adapter, every integration flows through that team and its backlog. For architects, team structure is therefore a genuine constraint on what can be built and operated. A team of seven cannot sustain five independently deployed microservices with their own on-call, so ShopNow built tracking as one Spring Boot service with two Kafka consumers. The inverse Conway manoeuvre uses the law deliberately, reshaping team boundaries to match the service boundaries you want instead of letting the existing org chart dictate them.

Ask four questions. Who imposed it, and with what authority: a regulator, a contract, a platform standard or one person's habit? What happens if we break it: legal penalty and lost licence, or only inconvenience and an uncomfortable conversation? Is it time-bound, such as a change freeze or a licence that expires? And what would it take to change it, meaning the cost and who must approve? The answers classify it as hard or soft. At ShopNow, "must use the old Oracle reporting database" turned out to be a preference tied to a licence ending in eleven months, so reports went to Athena instead. Challenge respectfully, with evidence, not as an argument.

Constraints help by shrinking the solution space, which makes decisions faster and easier to justify. Each real constraint eliminates whole families of options: AWS only removes Spanner and Cosmos DB, India residency removes global tables outside ap-south-1 and ap-south-2, and a team of seven removes a design with many microservices. In ShopNow's tracking design they cut twenty-four candidate architectures to three before any detailed trade-off analysis started. They also push teams toward creative responses, such as treating carrier SFTP files as S3 events feeding the same pipeline as webhooks. A design that clearly traces each choice back to a constraint is also much easier to defend in reviews.

Hard constraints should be enforced by the platform rather than by people remembering them. For data residency, an AWS Organizations service control policy denies any API call whose requested region is not ap-south-1 or ap-south-2, with exceptions only for global services such as IAM and Route 53. Cost ceilings become AWS Budgets alarms and tagging policies, runtime standards become admission controllers or pipeline checks that reject unapproved base images, and licence rules become dependency scanning in CI. Network constraints such as no internet egress from data subnets are enforced by routing and VPC endpoints. Automated enforcement turns a violation into an immediate, visible failure instead of a finding in next year's audit.

Team constraints shape architecture through deployable count, ownership and technology choice. Few teams favour fewer, larger deployables, such as a modular monolith or one service plus workers, because every independently deployed service needs owners, pipelines, dashboards and on-call. Teams organised by domain suggest service boundaries per domain, so ownership is clear and changes rarely need cross-team coordination. An existing platform team means using its paved road, such as EKS and standard pipelines, rather than inventing infrastructure. Skill gaps push toward managed services and simpler patterns, for example MSK with Spring Kafka plus training rather than a self-run cluster. Ignore these factors and you produce a system the organisation cannot operate.

Hidden constraints are expensive because they surface late, when the design has been approved, built or even deployed. A residency rule found during a security review can force a region change and data migration; an undocumented partner protocol found during integration testing can break the delivery date; a licence that charges per core, discovered after go-live, can turn horizontal scaling into a cost explosion. The results are rework, missed deadlines, compliance failures and lost credibility with stakeholders. The mitigation is to ask about every category explicitly at the start, involve legal, security, finance and platform owners early, and treat an unexplained "we can't do that" as a constraint to investigate.

Constraints belong in a constraint register kept with the architecture in version control, not in slides. Each entry has an ID such as CON-REG-01, a clear statement, its source and authority, its type as hard or soft, its impact on the design, an owner and a review date. Keeping it as YAML or Markdown beside the ADRs means changes are reviewed and history is visible. ADRs then cite the constraint IDs that drove each decision, so when a constraint changes you can find every affected decision quickly. The register should also be shown in design reviews and onboarding, and reviewed at least annually or when a trigger such as a licence renewal occurs.