1

Let's imagine we have a user object and we want to sync the state of this object through a service-oriented architecture using events. Regarding the event that is sent when the user is modified, I was wondering which of these options would be better for the body of the event:

  1. Sending just the fields that have been modified.
  2. Sending all the fields in the user object, leaving in the subscriber the responsibility to check which fields have suffered any modification.

In the example I am thinking of, the following would be a feasible scenario:

  1. In service A the field profile of the user is updated, and an event in the topic user-updated event is sent
  2. Service B, which is subscribed to that topic updates the user information, and as a consequence of that update the field contact-email of that user is modified. Given that the state of the user has changed, an event is sent to the same topic.
  3. Service A, which is also subscribed to that topic, receives the event and locally updates the contact-email field of the user. Given that the state of the user has changed, an event is sent to the same topic.
  4. Service B receives the last event where only contact-email has changed and tries to update the user. As there is no change between the existing user information and the received user information, there is no state change and no further event is sent to user-updated topic.

This process seems quite complex for me even though there are just 2 services keeping track of the state of the user. In a real example, the number of such services could be much higher.

Bustikiller
  • 2,423
  • 2
  • 16
  • 34

1 Answers1

0

Personally I would only send the modified fields, if nothing else, to keep the payload of the message small. Most messaging systems optimize/limit for small messages and do poorly when you send more than a couple K of data.

Also, I'm confused why you are doing a multi-master replication here. Why don't you have a single user service that both of these services send updates to and other services pull info from. You can cache the data in the client services, and then your event can become a cache-expiry, not a data replication event.

Rob Conklin
  • 8,806
  • 1
  • 19
  • 23
  • Thanks for your answer, Rob. Do you have any reference to somewhere that confirms the poor performance of big messages, or is it based on your experience? The user example is just an abstraction, for users, I would probably choose to have a single service and fetch the user information synchronously using an API, but I am facing this problem for several models across many services (where not of them need to have all the information about all models, just some). Also, we want to avoid having single points of failure, which is what we would get if we had a single centralized source of truth – Bustikiller Mar 04 '19 at 15:09
  • Understood, but I would still seriously consider modeling your domain such that you a single source of truth, and then cache the different representations inside the various services. Multi-master replication brings on some huge issues that are really hairy and expensive. From a size limit, Azure Service Bus has a 256K cap, as does AWS SQS. Other services have different caps, I know RabbitMQ is something stupid huge like 4GB, but then you are limited more on disk-paging activity than anything else. Regardless, generally you want the event, not the data, have the event be a pointer to data – Rob Conklin Mar 04 '19 at 16:20