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?

The distinction

A requirement is something you must achieve. A constraint is something you cannot change. The value of separating them is that requirements can be negotiated and constraints cannot, and teams waste enormous effort arguing with the second category.

• Exchange availability windows: constraint. No design makes an exchange answer at 3am.
• Settlement file arrival times: constraint, and one that dictates when reconciliation can run at all.
• Immutable audit record: requirement derived from a regulatory constraint. The regulation is fixed; how you satisfy it — append-only tables, an event log, write-once object storage — is open.

Why this is the highest-leverage twenty minutes in a design

Most architectural argument is about options that were never available. Once the constraint list is explicit and agreed, the remaining design space is small enough to reason about, and disagreement moves onto ground where it can actually be resolved.

The failure mode in a regulated fintech is the opposite: constraints are discovered late, usually by compliance, usually after a design has been socialised. A data residency rule or a seven-year retention obligation arriving in month five does not adjust a design, it replaces one.

The follow-on

A constraint should be recorded with its source and its expiry. "Exchange is unavailable overnight" has no expiry. "We must use the incumbent KYC vendor" expires when the contract does — and an architecture that treated it as permanent has hard-coded a temporary fact. Anti-corruption layers exist precisely for constraints with an expiry date.