Наверно это главный вопрос который задает себе архитектор при проработке решения. Мне кажется отсюда и родилась фраза «все зависит от контекста». Каждый раз при проектировании решения ты сталкиваешься с этим вопросом с разных сторон.

Например: Нам нужно спроектировать решение которое будет хранить и отдавать миллионы данных клиентов по запросу всем системам компании. Представим что мы знаем все требования и даже стратегию развития решения/продукта/компании. Что если стратегия поменяется? Сможет ли решение перестроиться за меньшие сроки, стоимость и усилия? Что если выбранные технологии на определенном этапе будут не эффективны? Тестирование технологий одна из самых сложных материй в моей практике, и всегда на ответственности архитектора и команды. Что если текущие требования не раскрывают реальный вектор стратегии? Например, мы решим поменять модель данных и будем менять ее регулярно, чем создаем постоянную точку изменений - регулярные задачи, генерирующие постоянную нагрузку на команду. А что если кто-то решить добавить не свойственную функциональность решению? Например, расчитывать метрики клиентов на основе событий, когда начальный вектор был в сторону хранить и отдавать, и событий клиентов в системе нет. Можем так сделать в этой системе?

Следствие: Может работать быстро, но долго и дорого что-то менять. Если не учитывать стратегию, то можно раза 3 полностью переписать всю или половину системы. Ответственность системы размывается и вот она уже делает много всего, за чем сложно уследить и оно начинает конфликтовать с основным функционалом. Технология работала на этапе MVP, но после подключения всех систем - генерирует серьезный поток проблем с производительностью или ещё с чем-то.

Лично для себя, я решил:

• тестировать технологии по большему количеству возможных кейсов самостоятельно, и до того как придется применить это решение, так как цена такой ошибки очень велика
• прогонять требования через себя, по 5 раз на грани абсурда и магии, формируя вопросы к бизнесу и точности их планов
• регулярно уточнять вектор стратегии и искать баланс между гибкостью и скоростью
• формировать в архитектуре подходы, которые создают основные точки гибкости (все к сожалению не покроешь)
• формировать возможности расширения границ системы и описывать их, в начале для себя, потом для всех остальных. Набор правил для принятия решений.

Вопрос «что если нагрузка значительно увеличится?» - не попал в список, так как это базовый вопрос при проработке НФТ и масштабирования решения.