This article develops the post published on LinkedIn: teams may spend weeks tuning queries, splitting loads and simplifying models. Improvements are initially visible, but each additional gain eventually requires more effort. At that point the question is no longer how to optimise, but whether the solution remains within its intended operating range.
Knowing when to stop optimising is part of architecture.
The diminishing returns curve
Optimisation is appropriate when it removes avoidable inefficiency. When a solution only survives through exceptions and increasingly narrow windows, the business may be adapting to the tool.
Five signals
- Every load takes disproportionately longer.
- Processes are split only to make them finish.
- Waiting consumes more time than analysing.
- Each optimisation delivers a negligible gain.
- Maintenance grows faster than value.
Evidence before preference
Architecture should balance volume, concurrency, latency, team capability, governance and total cost. Build a baseline, prototype the alternative and compare both scenarios. The decision then becomes one of capability and value rather than technological taste.