That’s an interesting question because it’s actually the second time someone asked me that in response to this article.

So I think keeping data in sync, with ACID like guarantees to keep, say, an order from getting shipped twice, is, in my opinion, a generic micro-service architecture challenge (a very solvable one), not a data mesh problem.

But I think, you are not thinking in terms of orders getting shipped twice, so let’s try to make this concrete, possibly with the examples I provided in the article:

• One customer context owned by team A,
• One order context owned by team B, emitting order data, providing it straight to consumers.
• One business intelligence domain owned by team C, ingesting the team B data, transforming it into something nice and providing it straight to consumers.

Your worry: both team B order data, and the team C order data (which is transformed in some way) might really differ => we end up with “data islands”.

In my mind the practical options to avoid this are already inside the data mesh approach:

• team C is a consumer of team Bs data. As such, the ingested data should have tight SLAs which define very clearly how accurate it is. As such, team Cs data shouldn’t differ too much from team Bs in general.
• team B and team C should have a very different consumer base and/or requirements on their data, otherwise, something is tracking strangely here. As such, the data provided really isn’t “the same”. Only one of those teams should be responsible for providing the revenue data which is used for making decisions like attributing budgets, etc.

So I guess what I’m saying is, provided the teams have good SLAs on their data, and act as “data product owners”, then I don’t see why it should be a problem that “data is different” or “out of sync”. But maybe you have a different use case in mind.