Как проверить требования по производительности на адекватность

Первый шаг — синхронизация по пониманию хорошей архитектуры.

Неправильно: считать, что хорошая архитектура для любого проекта, приложения, системы означает одно и то же.

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

Например,

пожелание заказчика: «Нам нужно, чтобы заказы попадали из CRM в систему начисления бонусов за секунду».

Задача ПМ/ПО/архитектора — задать вопросы: «Что будет, если доставка будет занимать две секунды? Пять? 30? 60?» и т. д.

Выяснить, где проходит граница между «хотим» и «возникают нежелательные для бизнеса явления».

Хорошая архитектура означает, что нежелательные явления не возникают.

пожелание заказчика: «Нам нужен высоконагруженый B2B-портал».

Задача ПМ/ПО/архитектора — выяснить, с какой нагрузкой порталу реально придётся работать в ближайшие пару лет: сотни сообщений в секунду? Тысячи? Миллионы?

Часто требование по высоконагруженности обращено в далёкое будущее, которое может быть и наступит.

Но человек ведь не покупает «Камаз» в качестве личного авто только потому, что когда-нибудь, возможно, ему надо будет перевезти что-то большое и тяжёлое.