A design decision is a comparison, and every comparison rests on inputs you estimated rather than measured: expected request rate, the share of reads, the cost of redoing lost work, how often a dependency fails, the price of a unit of capacity. Sensitivity analysis asks a narrow question about each of them. Hold everything else still, move this one input, and at what value does the winning option stop winning? Some inputs turn out not to matter; you can be wrong about them by a factor of ten and the choice is unchanged, so stop arguing about them. Others have a flip point uncomfortably close to your estimate, and those are the ones worth measuring properly before you commit, because your decision is really a bet on that number. Reporting the flip point is also what makes a decision reviewable: instead of writing that you chose one option because it seemed better, you write that it wins while the read share stays above a stated fraction, which tells the next person exactly what to watch. The flip points you find are the same values worth recording as assumptions with expiry, and the same ones worth turning into a check. You can now name, for a decision you have made, which input it is most sensitive to and the value at which you would decide differently.
Sensitivity analysis is the process of estimating how a target variable (an output or key performance indicator) changes in relation to changes in one or more input variables (assumptions), expressed…