Это если обращение в корне композиции идёт не через интерфейсы. В данном случае для каждого сервиса внутри монолита есть интерфейс, каждый сервис-проект не зависит от других (вся связь идёт в Application layer или корне композиции).

Без брокера и очередей же запросы могут теряться

брокеры - это асинхрон. когда вы про асинхрон расскажете разработчикам фронта, они будут в шоке :)

это делается немного подругому

Потому и завёл вопросы. Хочу понять тонкости)

А нужен ли api management, если api один?

надо смотреть в каждом конкретном случае, на API Management могут быть вынесены сервисные функции типа авторизации

Текущей реализации с Swagger + jwt вроде должно быть достаточно

Одного колеса и палки должно быть достаточно, чтобы поехать. Вот только надо сильно постараться, чтобы долго ехать на таком "моноколесе".

Потратьте время на изучение матчасти. Это потом окупится

Тоже недавно видел такое. Бекенд разработчик предложил

Мы тоже так делали :) но фронтам это тяжко

Изучать, конечно, буду. Сейчас собираю мнения, чтобы понимать, куда копать.

В итоге что вышло из этого?

Исправили на стадии HLA

То есть пока так:

1. LaravelAPI и Kafka убираем, на их место - какой-нибудь Management API.
2. Объединить в общий бэк можно, нужно только разделить api для веба и для мобилки по разным контроллерам. Либо делать микросервисы, но это overhead, как мне кажется.
3. Redis использовать только если api не будет справляться с нагрузкой.
4. Для мобилок лучше брать нативщиков, либо flutter, чтобы все было красиво.

По остальным вопросам пока не ясно.

Похоже на один из вариантов решения :)

6-8 слишком специфично, чтобы давать конкретные советы

Надо смотреть га профиль нагрузки и SLA как для решения в целом, так и для взаимодействий между элементами решения.

Переход на MSA не так страшен, как кажется. Нет кор вам в помощь

Взаимодействие между микросервисами, проброс контекста, консистентность данных, оркестрация... А стоит ли оно того?)

Стоит ли оно того никто кроме вас и не ответит