Hi Matthew,

Thanks for the response and the questions. Certainly, adopting this approach requires a fundamental mindset shift, and that's really the point of the article, to get folks recognizing that they don't need to live with the problems caused by "core services" and the tight coupling that they require. But indeed, it begs a lot of additional questions.

Regarding your first question, I'm assuming your scenario involves a new vertical product team that has spun up after the organization has decoupled its teams and moved away from the core services model. There are (of course) different approaches for seeding the new team's database. If we're using an event bus like Kafka, then that might provide our answer. Assuming we've been publishing new entities (say, Users) as well as their changes to a Kafka topic, then our new team could simply register a new consumer with that topic and begin consuming the User data. If that wouldn't work — say, the topic doesn't contain the complete set of Users — then we'd need a different approach. Any of your proposals could work, and which one would depend on our situation (e.g. volume of our existing User data, etc). In fact, I've seen hybrid approaches work successfully: initially, the new service retrieves User data "on demand", and later slurps in the remaining User data. Either way, we've made a decent compromise; we're temporarily enduring some runtime coupling, while avoiding unnecessary design-time coupling.

Regarding a "source of truth" for our data… I actually wrote about that a couple of years back. The long and short of it—at least, my take on it—is that the notion of a single source of truth is largely a myth, and certainly not something we should bend over backwards to try to have. What is more important IMHO is that, at least for any specific piece of information (say, a user's phone numbers) we try to have a single originating source; i.e. a single place where this data is ingested into our organization. That way, we ensure a unidirectional data flow as we propagate these events.

Regarding your third point; absolutely, it's a good idea to verify the consistency of our systems. Depending our needs, this might be simply monitoring our Kafka topics, or for very complicated systems it might involve building reconciliation jobs of some sort. The good news is that an inherent benefit of most async systems is resilience and fault tolerance.

Anyhow, great questions. I appreciate your forcing me to continue questioning and thinking about what I write. 🙂