Пожелания заказчика :
•  Отличное знание шаблонов интеграции корпоративных приложений (Hohpe) - Если мы говорим про издание 2003 года, то она в какой-то мере уже устарела (часть технологий упомянутых в книге умерло или считается жестким легаси). Однако архитекторы на собесах старательно задают по ней вопросы. В работе сталкиваюсь частично, т.к. нет подходящих задач на все шаблоны. На прикладному уровне имел опыт с ESB, IBM WebSphere MQ, Apache Kafka, имплементации RESTful на строне клиента и сервера.
В системах обмена сообщениями имел опыт:
- обмен файлами. Реализовывал интеграции как прикладной разрабочик.
- RPC. Разработка шаблонов обмена по SOAP в сбере. Java RMI практически полностью выпилили из кодовой базы на текущем месте работы (легаси).
- сервисная шина предприятия. Только в Сбере. Плотно взаимодействовал с командой интеграции как системный аналитик по проработке порядка обмена между разными системами. Сбер безуспешно пытался слезть с ESB в мой переиод работы там.
•  Отличное понимание принципов работы диспечеров обмена сообщениями. Опыт работы с Apache Kafka - только в проектах Сбера на уровне пользователя (поднять Kafka, перезапустить Kafka).
•  Опыт использования решений API Management - сталкивался в Сбере с IBM API Connect.
•  Знание большинства технологий из следующего списка:
SOAP - да, на текущем месте интеграции с несколькими системами,
REST - да, интеграция между фронтом и бэком,
XML, YAML, JSON - все форматы знаю, работаю с ними постоянно,
JWT - нет,
OpenAPI - да, работаю в Swagger. Сделал интеграцию по Gitlab API и базой знаний для вывода в плагин OpenAPI,
TLS, SSL - поверхностные знания,
OAuth 2.0 - использовали в Сбере. На текущем месте не использую,
SAML, gRPC - нет;
•  Уверенное знание SQL, а так же знание принципов реляционных и нереляционных БД - на уровне написания сложных запросов. На собеседовании покажу актуальные варианты. СУБД практически не админил. В последнее время работаю только PostgreSQL. Опыт с Oracle 2006-2014 годы, отказались в пользу PostgreSQL.
•  Уверенное знание SOA, MSA - понимание есть, на практике только описание WSDL, спецификацию RESTful и транспорт на HTTP знаю, в Docker игрался не так давно для собственного проекта. Хочется плотно попробовать с GraphQL в Apollo, на текущих проектах нет применения
EDA - только конкретную реализацию на Java Swing (уже легаси);

Столкнулся с интересным кейсом - у компании есть парк грузовиков, которые содержат электронику собирающую телеметрию, по приезду в гараж данные должны отправляться в различный софт. Как считаете, как это укладывается в обычные стандарты ИБ, где есть ДМЗ, есть "продакшн" контур?

А если СБшник не может выдать модель угроз - то нафиг он нужен?

Кто писал биллинг системы и подобное, какой подход чаще используется, хранить баланс отдельно и менять после транзакций или вычислять на основе транзакций?

Кто писал биллинг системы и подобное, какой подход чаще используется, хранить баланс отдельно и менять после транзакций или вычислять на основе транзакций?

Кто писал биллинг системы и подобное, какой подход чаще используется, хранить баланс отдельно и менять после транзакций или вычислять на основе транзакций?

Если точнее, то баланс на персистансе вычисляется не по каждой транзакции, а когда удобно (в начале дня, раз в 10 обращений, если не очень большая нагрузка и т.п.). А в памяти можно и актуальный держать все время.
Но вообще надо performance test делать.

Кто писал биллинг системы и подобное, какой подход чаще используется, хранить баланс отдельно и менять после транзакций или вычислять на основе транзакций?

Можно, например, высчитывать баланс и персистить его раз в сутки/час, а потом с этой точки отсчёта восстанавливать по транзакциям. Так даже лучше с точки зрения консистентности, потому что "баланс" точно не "отстанет" от лога транзакций.

Балансов может быть много и они могут иметь приоритеты

Кто писал биллинг системы и подобное, какой подход чаще используется, хранить баланс отдельно и менять после транзакций или вычислять на основе транзакций?

Зависит от сценариев. Я обычно от нагрузки плясал и активности по счету.
Т.е. как только накапливается сколько-то операций с последнего расчета - обновлял баланс. Тогда получается, что запрос баланса всегда одинаковое время требует.