Вопрос по поводу API

любая асинхронщина в разы сложнее, тяжелее и дороже синхронщины.

Это все имеет смысл при больших объемах данных и большом количестве запросов. Начните с выяснения надо ли вам это делать

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

Тут не хватает ключевого - а за что боремся? Будет точно дольше в разработке и в суппорте.

То, что описывается - это не event sourcing (от слова совсем). Ну и большого смысла от перехода на асинхронное взаимодействие вместо синхронного - тоже нет никакого.

У нас есть похожее: https://m.habr.com/ru/company/wargaming/blog/441708/ (мотай до Contract API)

Одно другому не мешает, я у себя делал когда запрос может сразу ответить результатом или ошибкой, а может и вернуть токен для последующего ответа. Через апи можно проверять как там дела по этому токену, через время будет ответ. У нас много оборудования которое может долго отвечать и ответ по такому запросу может например минут через 15 прийти

Еще важный плюс для систем, где время ожидания ответа на запрос может быть высоким. Тогда отдаем идентификатор запроса, и потребитель запрашивая ответ по идентификатору может получить статус "ожидание" или сам ответ, в зависимости от готовности. Это снимает риски таймаутов при ожидании быстрого ответа и в целом допускает некоторую деградацию скорости, прежде чем спохватиться и наращивать обслуживающие инстансы. Собственно, выше уже написали, не успел прочесть.

Асинхронное решение сложнее масштабировать. В нем появляется центральная база данных, к которой надо делать consistent write и consistent read на каждую операцию. Если операция связана с изменением данных в центральной базе, то это не добавляет избыточную зависимость, а если нет, то вы получаете новое узкое место в системе.

Асинхронные API больше подходят для потоковой и/или неравномерной нагрузки. В них важна общая пропускная способность и гарантия обработки, но в общем, неважна задержка при обработке индивидуальных запросов.Например, хитрый многостадийный конвейер с пакетной обработкой на стороне MQ может значительно поднять скорость потоковой работы, но индивидуальный реквест может в нем затеряться на много секунд.

По таким вводным звучит как усложнение ради того что разрабы хотят попробовать новое

Насколько я разбираюсь в CQRS - это не про синхронность/асинхроннось, а про разделение запросов на модифицирующие (команды) и немодифицирующие(запросы). Так что ничто не мешает CQRS быть как синхронным так и асинхронным.

Я бы так не делал без особой необходимости. Гемора _очень_ много, профит неясен

Теоретическая рекомендация — переходить на асинк при деградации. Ну а так, давай инструменты — команды выберут . Делать как обязаловку — все таки перебор , хоть и красиво .

Делать такое как общий механизм на уровне app layer выглядит немного сомнительной идеей, если сразу не говорить о транспортном протоколе и деталях реализации. Потому что от них будет зависеть latency в итоге. И может получится, что синхронный HTTP вызов будет иметь даже более низкую latency.

А как вы будете server-sent-messages на бэке делать? Там все не очень очевидно, увы. Ну и неудобно в использовании, конечно. И придется решать кучу разнообразных проблем с синхронизацией

Если можно сделать api с клиента синхронным — нужно делать синхронным. Плюсы синхронного АПИ во много раз превышают минусы (время разработки, стоимость разработчиков, простота тестирования и т.д)

Попробую поделиться скромным опытом на кейсах. Кейс первый. Есть у тебя запрос, под которым может быть не совсем предсказуемая по времени операция. Теоретически долгая операция. Много чего может затрагивать и по тайм-ауту может отвалиться. Тут наверное один из вариантов - асинхронность. Добавляем и боль проходит. Не добавляет - оно взрывается на первом тестировщике, который решает что-то побольше прокачать чем минимальные данные (проверено на практике). Если теоретически может быть очень долго но на практике не получается никак - возможно и не стоит париться. Второй случай. Делаешь системную нагрузку и потом имеешь, что без очередей и опять же асинхронности беда. Захлёбываемся. Масштабировать больно и дорого или вообще потолок и неликвидность накрывает. Делаешь асинхронность. Переделываешь. Настраиваешь. Перенастраиваешь. Неожиданно боль проходит. Потолки пропадают. Всплески нагрузки не страшны. Автомасштабирование поспевает за нагрузкой. И прочие прелести и розовые пони. Но опять же не дёшево в самой разработке и отдадке. По кр мере первый раз. При этом и в первом и во втором кейсе попытка завернуть в синхронщину заканчивается плохо. Очень плохо. И при этом оказывается что в идеале нужно ещё кое-чего по итогам в техдолг положить чтобы работало хорошо и красиво. Кейс третий. Есть у тебя метод, отрабатывающий за миллисекунды и хороший по всем нагрузкам. Ты его делаешь асинхронным ибо так есть модно. Даёшь нагрузку и оказывается что оно работает медленнее, стоит дороже и ресурсов требует существенно больше. Чешешь репу. Откатываешь уже другую репу на состояние "до". Итоговые выводы от кэпа таковы: 1 - решать конкретную боль при её возникновении хорошо, 2 - решать боль которой нет - плохо, 3 - "всё под одну гребёнку" редко работает хорошо, 4 - асинхронность сложнее и дороже и больше подводных камней, но иногда без неё никак или очень дорого, 5 - асинхронность не приносит пользы и даже вредит там, где она не нужна. Рекомендации: воткнуть асинхронность там где она нужна и без неё будет очень больно и это точно, 2 - не втыкать асинхронность там, где она не нужна.

делали на основе rabbitmq (async by design), поверх которого синхронный/асинхронный xml api endpoint

Сложнее разрабатывать, а профит неясен

by default отложенное исполнение смущает. Используем и то, и то с очередями и все такое, но... Поведение зависит от службы, которая стоит за конкретной точкой API, а само API это прослойка (обеспечивает авторизацию, запросов, единую спецификацию запросов и ответов, "транспорт" запроса в нужную службу). Как-то так.

Прочитав обоснование, я пришёл к выводу, что разработчикам очень хочется сделать Абсолютно Инновационный Проект, Который Никто До Них Не Делал.

Звучит, как гора велосипедов для замены gRPC.

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

>асинхронность из коробки, значит более отзывчивый интерфейс

Далее, постановка задания в очередь с получением идэнтификатора -- это само по себе имеет какие-то затраты времени. Если верхняя оцэнка времени выполнения задания меньшэ верхней оцэнки времени постановки его в очередь -- то это получается очень странное развлечение, пытаться добиться отзывчивости таким способом. Если сопоставимо -- то просто странное.

Ничто не мешает сделать реализацию под синхронную и асинхронную модель одновременно. И определять на уровне конфига или интерфейса, что делать с объектом команды|квери после попадания в медиатор: либо сразу в хендлер, либо в очередь.С асинхронщиной неприятно, что появляется куча хранилищ, какие-то воркеры, которые надо как-то обслуживать. Если это не делается как общий подход для всей компании, лучше наверное не делать, чтобы не плодить внутренние невзлетевшие фреймворки.

Как обеспечивается консистентность? Каковы затраты на обеспечение консистентности? Что будет, если MQ потеряет сообщение?

Мотивацию разработчиков я понимаю, им за такой cloud native будут очень хорошо платить на другом месте работы)

Это хороший способ сделать систему, которая будет выдерживать высокие нагрузки и масштабироваться. Поддержу ваших разработчиков!

Что касается отзывчивости пользовательского интерфейса... у меня на практике было всегда даже наоборот - вот именно в пользовательском интерфейсе это всегда означало дичайшие лаги. Ну просто потому, что у пользовательского UI и очереди трейдоыы сделан в разные стороны. Пользователь хочет получить ответ на нажатие кнопки мгновенно, а очередь хочет вернуть данные когда нужно ей. Если нажатие кнопки ставит запрос в очередь - и пользователь продолжает жать и жать кнопку и ожидать ответа - то в очереди скапливаются сообщения. Чем больше их скапливается, тем больше их протухает по таймауту. Откуда взялся тайм-аут - ну, пользователь же не хочет ждать ответа вечно, через минуту ответ на нажатие кнопки больше не актуален. Образуется паразитная положительная обратная связь. У пользователя «интерфейс лагает». Так что это опять чисто экономический вопрос - готовы ли мы наши сэкономленные деньги превратить в страдания пользователей. Наверное, ну если очень сильно экономим - то да. А иначе синхронные запросы с гарантированным временем ответа куда приятней

Около 3х лет жил с промежуточным решением: api был синхронным, на бэкэнде любое действие пользователя заворачивалось в команду (с предварительно сгенерированым uuid если что-то предполагалось создать). Команда выполнялась синхронно, не возвращала ничего но могла упасть с исключением. Данные для ответа выбирались заново. Случаев когда нужна была асинхронность были действительно единичные, решал каждый раз по-своему на стороне клиента: чаще всего делал несколько попыток запросить данные по uuid с интервалом в секунду - если система не упала этого хватало в 99.9% случаях.

Идея хорошая и правильная, но реализация может все убить. Чтобы этого не произошло, надо иметь постоянный двунаправленный канал обмена сообщениями с сервером и batch submission.