В моем понимании микросервисов - они будут независимы и слабо связаны по своей природе - поэтому лучше всего относиться к ним как к таковым - предположим, что они вообще не понимают контексты друг друга. Однако эти процессы кажутся очень тесно связанными с тем, что вывод одного из них почти гарантированно является вводом для другого.
Пользователь - звучит похоже на идентификацию / аутентификацию, которая может быть извиняется как обязательное условие для других сервисов - если не для аутентификации, но для требуемого контекста.
Кроме этого - это звучит как вопрос - где организован процесс? В клиенте (ваш вариант 1)? Или в другой «центральной» службе, вызывающей микросервисы от имени клиента (ваш вариант 2)?
https://dzone.com/articles/microservices-using-saga-pattern предполагает, что обмен сообщениями о событиях также можно использовать, чтобы избежать организации центральной службы процесс - но каждое из микросервисов должно быть подписано на другие события и знать, когда выполнять свои собственные процессы.
Для меня - Если ваши сервисы действительно независимы (например, управляются разными поставщиками, разными базами кода) et c) тогда я бы организовал на клиенте.
Если пользовательский интерфейс этого пользователя является лишь одним из многих (несколько приложений, которые могут создавать продукты) - тогда я бы создал «центральный» сервис оркестровки в чем-то вроде Enterprise Service Bus. Это делает оркестрированный процесс многократно используемым.
Если у вас есть полный контроль над этими всеми этими микросервисами, и они являются частью одного и того же стека решений, то я бы встроил необходимые проверки правил в службу micros продукта и сделал это одна транзакция. Вы все еще можете сделать это RESTfuly, используя команду POST / PUT.
Это даст хорошую диаграмму - будет рад рисовать, если вы считаете, что это поможет.
Открыто для ваших (и других) мысли.
Крис