Counterfactual Structure Test

Given forty requirements, an architect needs to know which three or four actually determine the shape of the system. Importance is the wrong filter, because a legally mandatory feature can still be a feature, and a commercially trivial latency number can be the thing the whole topology exists to serve.

The test: strike the requirement out and ask whether the structure would be different. If yes, it is a driver. If no, it is a feature the structure will host.

Why it matters

Without an agreed driver list, every trade-off is argued from first principles every time, and the loudest stakeholder wins. With one, "that would cost 150ms on the order path" ends a conversation on evidence rather than on taste. Drivers are what an architect uses to say no.

They also tell you where to spend design effort. Most of a system deserves the obvious structure; the small part touched by a driver deserves several days of argument.

Implementation patterns

• State each driver as a number, not an adjective. "Fast" cannot be struck out and tested; "p99 order acknowledgement under 200ms during the market open" can.
• Name the counterfactual explicitly in the design document — "if this were 2 seconds instead of 200ms, we would run one database and no isolation" — so the reader can see what the number bought.
• Attach a fitness function to each driver. A driver with no automated check is a slogan, and slogans do not survive eighteen months of individually reasonable commits.
• Re-run the test annually. Drivers expire. A latency target set when the product was a niche tool may be irrelevant once the customer base changed.

Industry example

For a quick-commerce platform such as Zepto, striking out the ten-minute promise removes the dark-store network, the per-store inventory projection, the geospatial dispatch, and the entire reason stock is held in memory close to the store rather than queried from a central catalogue. Striking out loyalty points removes a service. One is a driver; the other is a feature, and they are not distinguished by how much revenue they influence.

For Zerodha the driver is the market-open burst: strike it and the order path no longer needs its own datastore, its own connection pool, or physical separation from portfolio views. For a multi-tenant SaaS such as Freshworks the driver is isolation under a ten-times outlier tenant, which is why quotas, partitioning and worker allocation exist at all.

Failure scenarios

• Everything is a driver. A list of fifteen produces no prioritisation and no refusals, which is the same as having none.
• The driver is a slogan on a wall rather than a number in a pipeline, so it degrades invisibly.
• Drivers are set by whoever writes the document rather than agreed with the business, so the first serious trade-off exposes that they were never authoritative.
• Expired drivers are still honoured, and the system carries expensive structure for a promise the product no longer makes.

Trade-offs

A short driver list makes the architecture opinionated, which is the point, and also makes it brittle to a change in business direction — because a driver removed leaves structure that no longer earns its cost. That is an acceptable trade only if drivers are revisited deliberately rather than assumed permanent.

The opposite failure is worse and more common: refusing to name drivers in order to stay flexible produces a system with no design centre, which is optimised for nothing and expensive at everything.

Interview question

"Here are forty requirements for a delivery platform. Which three are architectural drivers, and for each one, tell me what the architecture would look like if you deleted it."