Technical Constraints

A constraint is not a failure of imagination; it is part of the problem statement. An architect who designs as though the estate were greenfield has designed something that will not be built.

The categories that actually bite

• Estate. A mainframe of record, an ERP that owns the item master, a data centre with three years left on its lease.
• Skills. A team of forty who know Java and one person who knows Go.
• Commercial. Licences priced per core, a vendor contract with two years to run, an egress bill that makes a design uneconomic.
• Organisational. A change window of one release per month, an approval board, an outsourced operations partner.
• Regulatory. Data residency, retention floors, audit obligations.

Industry example

Walmart's architecture is shaped by a constraint most digital-native designs never face: physical stores and distribution centres are part of the system. Inventory is not a number in a database; it is an estimate of what is physically on a shelf, degraded by theft, damage, misplacement and in-flight picking, and reconciled by periodic counts.

That constraint propagates upward. It means availability shown to a customer is probabilistic, so the architecture must carry safety buffers, reservation semantics and a substitution and refund path as first-class flows rather than as error handling. It means store systems must keep selling when the network to the centre is down, which forces local autonomy and later reconciliation. And it means the peak is not a marketing decision — it is the day after Thanksgiving, known years in advance, which makes pre-provisioning a rational strategy where an unpredictable workload would demand autoscaling.

An architect who modelled inventory as a strongly consistent integer would be technically correct and operationally wrong.

Trade-off

Constraints can be challenged, and sometimes should be — but challenging one is a separate project with its own cost and sponsor. Confusing "this constraint is bad" with "I may ignore this constraint" is the most common way architectures fail to survive contact with the organisation.

Interview question

"You are told all data must remain in-country and the incumbent ERP cannot be modified. How does that change your design, and which constraint would you push back on first?"