During preparation for an extreme flash-sale event, who should own the decision to disable a non-essential feature under load - the architect, the product owner, the on-call engineer, or an automated policy? Choose and justify.
Show the full answer Hide the answer
The reasoning
At the peak of a synchronised demand event, the window between "load is rising" and "the system is unrecoverable" can be under a minute. Any decision requiring a human in the loop is not a decision; it is an aspiration.
But automation without prior agreement is worse — an engineer's implicit judgement about which features are expendable, encoded in code, discovered by the business afterwards.
The right division of decision rights
The architect owns the mechanism. What can be shed, at what granularity, in what order, with what recovery. Whether shedding is by feature, by tenant, by request class or by percentage. How the system behaves at each rung. This is an architectural property and must be designed, tested and exercised long before the event.
The product owner owns the ladder's ordering. Which capabilities are expendable and in what sequence — recommendations before reviews, reviews before search filters, filters before checkout — is a business judgement about revenue and customer trust, not a technical one. The architect should refuse to make it alone, and equally should refuse to let it go unmade.
The automated policy owns execution. Triggered on measured signals — queue depth, latency percentile, dependency error rate — not on a human's read of a dashboard.
The on-call engineer owns override. They can force a rung up or down and stop the automation, but their default action during the event is to observe, because the ladder was agreed in advance precisely so nobody has to improvise.
What the architect's job actually is here
Not to make the call during the event. To ensure that the call has already been made, encoded, tested under realistic load, and is reversible. If the architect is making decisions during the peak, the architecture was incomplete.
The failure this prevents
The common failure is a degradation capability that exists in code, has never been exercised, and is triggered for the first time under peak load — where it turns out that shedding recommendations also breaks the homepage, because the fallback path was never run. A degradation ladder that has not been rehearsed is not a control.