Мутаген,

Ну посмотрели и что в ней такого особенного? Всё +/-, как у многих.
Если правильно понял Postgresql стек это больше для Camunda и сервисов с хранением состояния (хранение, мониторинг, исполнение бизнес процессов).
Elk - это уже фактически стандарт в Enterprise для логирования с последующим разбором полётов.
Kafka используется, как интеграционная шина (не совсем её применение, но почему нет? работать будет).
От JBOSS FUSE там скорей всего только сервер приложений причем без кластера/1 нода с одним приложением (принять json, отвалидировать и кинуть в kafka). Сама кластеризация происходит где-то на уровне системы/кубера.

Там кстати выше еще есть картинка с продуктовой витриной реализованной на ClickHouse. Для витрин всё таки больше подходит не стандартный json/swagger/rest, а что-то типа odata/graphql, но при желании можно и на ресте накостылить. Также витрина это 99.99% запросов на получение данных (GET). На первый взгляд архитектор не доработал (слишком много прослоек, все данные должны быть в ClickHouse) - отдача от витрины должна быть мгновенной, но возможно есть веские причины (лень).

Что не понравилось, что Camunda будет использоваться для оркестрации, но часть логики вынесена в микросервисы (тоесть логику бизнес процесса размазали (предположение), по диаграмме невозможно будет понять, как работает бизнес процесс). Очень сложно будет тестировать процесс.

ТЗ, конечно, только "попу" подтереть (обычное, откатное, что не новость). Дать по нему оценку разработки невозможно. Даже юридический документ и то гораздо больше. Тут нужно для начала оркеструемый процесс нарисовать и все задействованные в нем "service task". Потом по каждому сервису еще по ТЗ.