Constraint Expiry

Constraints are the things you cannot change, and separating them from requirements — the things you must achieve — is the highest-leverage twenty minutes in most designs, because most architectural argument is about options that were never available.

But constraints are not equal in durability. An exchange being closed overnight has no expiry. An incumbent KYC vendor expires when the contract does. An architecture that treated the second as permanent has hard-coded a temporary fact, and unwinding it costs far more than the vendor switch it was supposed to enable.

Why it matters

Undated constraints accumulate, and after a few years a significant fraction of a system's structure exists to satisfy facts that are no longer true. Nobody notices, because there is no artefact that says when to look again.

Implementation patterns

• Record source and expiry for every constraint: who imposed it, under what authority, and when it can be re-examined. "Permanent" is a valid expiry and should be stated rather than assumed.
• Put an anti-corruption layer where the expiry is real. Vendor-shaped constraints, jurisdiction-shaped constraints and integration-shaped constraints all deserve a boundary; a law of physics does not.
• Review the constraint list at the same cadence as the driver list, annually, and treat an expired constraint as a design opportunity rather than as trivia.
• Distinguish regulatory constraint from the chosen means of satisfying it. "Immutable audit record" is a requirement derived from a constraint; append-only tables, an event log or write-once object storage are competing designs, and conflating them freezes an implementation choice as though it were law.

Industry example

A brokerage such as Groww lives inside three genuine constraints — exchange availability windows, fixed settlement-file arrival times, and regulatory retention — and typically several dozen temporary ones: this KYC vendor, that market-data feed, the current clearing member's file format, a legacy identifier scheme.

The costly pattern in regulated fintech is the reverse of expiry: constraints discovered late. A data residency rule or a seven-year retention obligation arriving in month five does not adjust a design, it replaces one — which is why the constraint list is gathered before the design rather than validated after it.

Failure scenarios

• A vendor's data model becomes the domain model, so switching vendors means rewriting the core.
• An expired constraint still honoured, with structure maintained for a fact nobody has checked in years.
• Constraints discovered late by compliance, after the design was socialised and estimates given.
• A constraint asserted without a source — "we can't do that" with no traceable authority — which cannot be challenged and cannot be removed.

Trade-offs

Anti-corruption layers are not free: they add indirection, translation code, and a second model to keep in sync. Putting one around every constraint produces a system where nothing is direct.

Spend them where the expiry is real and the switching cost is high — payment providers, KYC vendors, logistics carriers, market-data feeds — and go direct where the constraint is genuinely permanent. The expiry date is what tells you which is which, which is the reason to record it.

Interview question

"List the constraints on your current system. For each one, who imposed it and when does it expire? Which of them have you designed a boundary around, and which are load-bearing in your core model?"