Hello @chenhai ! I took help from a more experienced colleague on this topic and he replied this :
"Well.. AD482 is focused on event architectures.. that means that even if your application has shared state, then there is the problem of eventual consistency.
That means that, from design, there is no easy way to guarantee that an event thrown by microservice A is processed instantaneously by microservice B.If we have a microservice B that accepts a request that depends on a change applied in A is propagated, and you can't live with the eventual consistency, it might be a sign of the separation between A and B, is artificial and they should not be separated (or at least the logic that is very tied to what happens in A)
You can use DDD to properly separate responsibilities but that doesn't mean that its the final solution.To mitigate the problem you can implement patterns as the transactional outbox and saga.
Some people might end coupling Microservice B to the Microservice A database, that can be a patch, but not a good solution.
In my previous life as developer I worked on a transactional team dealing with bookings + payments + complaints, and we we lived happily with the event consistency.. even when dealing with $$.
It's a matter of how you implement the whole solution and what are you looking for.
We wanted the whole app to be resilient, and we can live with some stale information while the events were propagated ."
