A design tactic is never free. Adding a second machine buys availability and spends money, and it spends simplicity too, because now something has to decide which machine answers. Putting a cache in front of a database buys latency and spends freshness, since the cached answer is an older answer. Adding a queue between two components buys the ability to survive a slow consumer and spends end-to-end time and the certainty that work finished. Splitting one deployable unit into several buys independent release and spends the ease of a single change. The useful habit is to stop describing a tactic by what it improves and start describing it as a pair: the attribute it buys, and the attribute it charges. Write the candidate tactics down the rows of a small table and the quality attributes you ranked across the columns, then fill each cell with a plus, a minus, or a blank. The table will not choose for you, but it makes the argument visible, and it exposes the tactic that costs an attribute you already promised a number for. That is the one to reject early. You can now state any tactic you are considering as a purchase with a named price, and put a set of candidate tactics into one table that a reviewer can read in a minute.
Video tutorial: Evaluating Software Architecture Tradeoffs and Risks Using ATAM