Constraint Removal Risk

Systems accumulate friction: rate limits set for a forgotten reason, queue bounds nobody chose deliberately, manual approvals from an old incident, deployment processes that are slow because they always were, connection caps inherited from a previous architecture.

Friction is a legitimate target — it slows delivery and frustrates people. But a constraint that has been in place for years has been doing something, and what it has been doing is frequently not what it was created for.

Why it matters

The effects of removal are second-order and delayed, so they are rarely attributed to the change. A rate limit removed in March produces a database saturation incident in July, investigated as a capacity problem. A manual approval removed for velocity produces a configuration outage a quarter later, investigated as a process failure.

The team that removed the constraint is usually not the team that experiences the consequence, which eliminates the feedback that would otherwise teach the lesson — and is why this pattern recurs in the same organisation repeatedly.

Implementation patterns

• Before removing any limit, gate or throttle, establish what it currently prevents. Not what it was created for — what it is currently doing, which is answerable by measurement: how often does it bind, what happens in the moments it binds, and what would the system do without it.
• Ask what would change downstream. A limit removed at one layer becomes load at the next, which was protected by it.
• Remove it behind a flag, so the removal is reversible and the effect is attributable.
• Instrument the thing you expect to be affected before removing the constraint, so the second-order effect is observed rather than discovered later.
• Replace rather than remove where the function is real: a manual approval that was catching configuration errors is replaced by automated validation, not by nothing.
• Remove one constraint at a time, since simultaneous changes make effects unattributable — which is why "we improved five things and something got worse" is such a common and irresolvable situation.
• Record what was removed and why, so the next incident's investigation has the information.

Industry example

The most consequential recent form of this concerns deployment and configuration friction. Organisations that automated away staged rollouts, approval gates and bake periods in pursuit of velocity discovered that the friction had been providing blast-radius limitation — most visibly in incidents where a change reached the entire estate within minutes.

The CrowdStrike 2024 incident sits in this family: content updates were delivered on a fast path with less validation than code, precisely because speed was the point and the friction applied to code had not been applied to data. The rigour that was absent had been unnecessary for a long time, right up until it was not.

The same shape appears with rate limits removed from internal APIs, queue bounds raised to stop rejections, and connection pool caps increased to eliminate wait times — each of which converts a visible, bounded failure into an invisible, unbounded one.

Failure scenarios

• A rate limit removed, so a downstream database receives load it was previously shielded from.
• A queue bound raised to stop rejections, converting fast failure into unbounded latency for everyone.
• A manual approval removed that had been the only validation of a configuration change.
• A slow deployment made fast, removing the bake time in which defects had been surfacing.
• A connection pool cap increased, moving contention from the pool to the database.
• Automation replacing a manual process whose operators retained the skill, which is then unavailable when the automation fails.
• Several constraints removed at once, making the resulting incident unattributable.

Trade-offs

Taking this seriously slows down the removal of genuinely useless friction, and there is a great deal of genuinely useless friction. An organisation that investigates every limit before touching it will keep most of them, which is its own failure — process accretion is a real and serious problem, and constraints do frequently outlive their purpose entirely.

The investigation itself is also sometimes impossible. Nobody remembers why the limit is 200, the person who set it has left, and there is no record. In that case the answer is not to keep it forever but to remove it carefully — behind a flag, with the downstream instrumented, one at a time.

The trade is delivery friction and investigation effort against the risk of removing something load-bearing. The proportionate rule is that the investigation should scale with what sits downstream: a limit protecting a shared database deserves an hour of thought, and a limit on an internal tool used by four people does not.

Interview question

"A team wants to remove a rate limit on an internal API because it is blocking a legitimate use case, and nobody knows why the limit is set where it is. Tell me what you would want to know before agreeing, and how you would let them proceed without waiting for a complete answer."