0

We're currently considering building an app's backend using an Event Driven Microservices Architecture. From what I've learned, this means you should be replicating data which is used by multiple services using asynchronous messaging, instead of directly querying the data holding service.

Imagine we need to implement a service, which holds lots of foreign keys from other services, e.g: market ID's, user ID's, and few others. The service should not just respond with the plain ID's, but map them to their according names, e.g: idmarket1 -> "Walmart", idname1 -> "John Doe".

Option 1: Providing both the ID's and corresponding names in the post request to create a record, along with the other fields. This could lead to users messing with the API to be able to manipulate the names.

Option 2: Replicating the ID-Name-Pairs to the service via a pub sub message broker, whenever a new record is created in one of the others stores owning the data.

The second option seems like the way to go for me, but I'm not sure if it's really the best practice to be replicating such small chunks of data, each in an extra table.

Are there any other options or best practices, I haven't considered yet?

2
  • Your question is covered in some detail here. Dec 22 '21 at 2:28
  • Do you need all that data in every microservice? I suggest you read up on the concept of aggregates and identify your aggregate objects and their associated events.
    – Asad Iqbal
    Jan 6 at 12:19
0

Personally, I don't think an Event-Driven Architecture should be about replication data at all. It should be about sharing Events. In a typical application, this would be a business event.

I have seen many attempts to implement Event-Driven ... [put your favorite architectural concept here]. Some were successful, some failed miserably, and most stayed acceptably maintainable. The one thing I noticed made a difference between these results, was the amount of low-level coupling between the components that emitted and processed the events. Keeping events focused on actual business events keeps the component tied to the business logic, rather than technical choices made with the best intentions. As you gain new insights, sooner or later, you will regret those choices.

To answer the question "what data to put in events"; include all the data that you need to describe the (business) event.

Not the answer you're looking for? Browse other questions tagged or ask your own question.