для расписала нашего монолита из-за проблем с масштабируемостью
Не очень понял связь между монолитом и масштабируемостью. Если следовать
вот этим правилам, то любой монолит будет отлично масштабироваться. Я бы на вашем месте проект привёл именно к соответствию этим правилам, а не спешил перелезть на микросервисы, т.к. и у них проблем хватает.
Проблема 1:
Почему только 3? У вашего магазина нет авторизации? Есть - это отдельный микросервис. Рассылка элетронной почты есть? Есть - ещё один микросервис. Смски шлёте? Ещё один. Другое дело, что писать это всё, понятное, дело должен не один человек, и, скорее всего, не всё на php.
Проблема 2:
Последовательно (синхронно) в кучу сервисов никто запросы не делает. В Guzzle (библиотека для http-запросов) есть асинхронный режим, кстати. То есть можно сразу сделать обращение к нескольким сервисам и собрать результаты (время будет равно времени выполнения самого медленного запроса). Но вы и с фронтенда можете сделать обращение к нескольким сервисам сразу асинхронно ведь. Если вопрос в авторизации, то для этого можно использовать jwt-токены - их каждый сервис может сам валидировать. Также можно кешировать данные в определённых ситуациях и даже дублировать в разных сервисах (в микросервисной архитектуре это допустимо).
Проблема 3:
Обычно никак не решается, как ни странно. Распределённые транзакции - это боль. А общую базу для нескольких микросервисов использовать нельзя - это антипаттерн.
P.s. возможно, в вашем случае не нужно всё дробить на кучи микросервисов. Это долго, дорого, трудоёмко - и сложно сделать так, чтобы было удобно, особенно когда опыта нет. Попробуйте что-то одно отделить по мере надобности, потом другое. А дробить бездумно точно никакого смысла не имеет.