Hi Joao, thanks for your response. Regarding your question: in the context of this article, a core service is one which is owned by one team, but is actually used by multiple other teams. Furthermore, the core team owns the service not because they have an expertise in the subject matter, but simply because the subject matter is used across the organization.

So if Team A wants to read user data, they need to call out to this team’s service, rather than just hitting their own database. Likewise if they want to persist any data about a user: they can’t simply write it to their own data store, but must cross bounded contexts to write the data. In practical terms, this means that Team A is wholly reliant on the availability of the core service (i.e. a “runtime dependency”).

Furthermore, if Team A wants to make a change to the user data that is stored, then they are at the mercy of—at a minimum—the availability of the core services team to work with them. They might also be blocked by the availability of the other teams that also rely on the core user service (i.e. a “design-time dependency”).

These dependencies hamper performance, availability and productivity, and—as the article argues—are often unnecessary.

With event publishing, Team A can now maintain their own user data. They can design their own database schema and enhance it as they see fit. Event publishing allows this, because it allows the other teams’ services to be aware of any changes to users’ data that are made by upstream services, thus allowing the data to stay in sync.

I can see your point about the article being about why it's a bad idea to share core service data through REST (I assume by REST, you’re really referring to any form of synchronous communication). That might be true, but it goes even further than that. The main idea is avoiding the runtime and design-time coupling, plus the idea that one central team “owning” data simply because more than one other team consumes it can be an anti-pattern.