Подскажите пожалуйста, а я могу вот такую штуку использовать? rpc,

только реализованное в реббите https://www.rabbitmq.com/tutorials/tutorial-six-php ( или https://habr.com/ru/articles/747644/), там есть correlation_id, страховка от network otage и прочего, как вроде бы то, что мне нужно, этакая защита от дуплицирования запроса во втором сервисе. а полноценную сагу тащить для всего двух сервисов мне кажется накладно
Вот выдержка из статьи, звучит как то,что мне нужно
мы подписываемся на специальную псевдоочередь amqp.rabbitmq.reply-to
отправляем сообщение с указанием этой очереди в качестве reply-to заголовка
кролик генерирует для нас уникальный routing_key, по которому будет должно быть опубликовано ответное сообщение в default exchange
сервер получает наше сообщение и отправляет ответ по этому routing_key.

Стикер

Не хватило информации: 1. Можно ли запросы выполнять параллельно? 2. Что будет, если не смогли отправить во второй сервис? Надо ли откатывать?

Если не смогли/второй сервер не ответил на данный запрос, то откатывать

Для резных пользователей можно

Нет, но какую-то защиту хотелось бы сделать, тк через grpc второй запрос бывает дублируется

Только на кролике такое надежно не построить.

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

Такой outbox pattern применить?

А какой вариант тогда +- надёжный? Ведь это мне кажется стандартная проблема.

Вам же надо откатить, если второй сервис не ответил. Если сервис умеет отвечать, что операцию не выполнил и не сможет, тогда хореография на базе событий. Возможно, даже кролика хватит. Если сервис не умеет ясно объяснять, что не так, а только ошибку возвращает, то оркестрация, а в этом случае нужен дирижер (например, temporal).

Это если он принимает, что не может, а если какая-то сетевая ошибка. Я же по сути жестко хочу контролировать связку запрос - ответ