Is publishing to the same event store stream from multiple places an anti pattern in a distributed transaction?

Question

Below is a little context to the problem I'm trying to solve.

There are two separate microservices with separate frontends , APIs and databases.

• Customer Microservice - Manages customers
• Orders Microservice - Manages orders

Orders table has a dependency on customers and so in Orders Microservice database customer schema is duplicated. To synchronize the data we use Event store (https://www.eventstore.com/) which uses publish/subscribe model and persists data on separate streams. Example on diagram below.

Now in normal scenarios if someone adds a new customer using Customer Microservice it publishes data to the stream and then it's synced to Orders Microservice which is subscribed to the stream.

However we have a business requirement now to be able to place an order and add a customer at the same time. Basically this is a case of a distributed transaction in microservices.

Now the scenario I was thinking on how to solve this is as follows:

1. API call is made to Orders microservice and data persisted to both orders and customers tables in Orders database in a single transaction.
2. In the same API call we also publish customer data to Event store stream. Then it's published to both Orders and Customers databases. If the event is idempotent double write to customers table in Orders microservice isn't an issue. This allows us to achieve eventual consistency. We don't have a requirement for hard consistency here.

Now finally the questions:

• Is it an antipattern that both Customers and Orders would be publishing Customer data to the same stream in Event store (Orders would be using API call for that and Customers a UI with a CRUD)? This causes some potential issues for example with validations since they have to be duplicated in two places
• Would it be also a good idea to add some kind of a bool flag to customers table to make sure record is considered valid only in case it was populated by event store subscription ? We consider event store a single source of truth.
• Is there a better approach to the problem I presented ?

Answer 1

Presumably, you would never want an Order without a customer, but, you might have a customer without an order?

In which case; you can make it two separate calls.

1. Create the customer (raise the CustomerCreated event)
2. Listen for the CustomerCreated event in your Orders service and create a customer record
3. When the order is processed - match up the Order and Customer records in your Order Service

I would strongly suggest you dont want to be created the same two events in different services because that indicates that your bounded contexts are not correct.