1

I was wondering what should be the granularity of the topic names in an event-driven service-oriented architecture.

Let's imagine we have a user management system where users can perform different actions like signing up, signing in, modifying some profile attributes, etc. If we wanted to notify the rest of the services of these changes, I can think of some possibilities for the topic naming:

  1. One topic per each of the classic CRUD operations in each of the models (excluding read since the state of the user does not change). We would have user-created, user-updated, user-deleted. This approach is generic enough, but there would be potentially many services subscribed to user-updated topic and discarding all those events that do not modify a specific field.

  2. One topic per business-relevant change. In addition to user-created and user-deleted, we could have events like user-email-updated, user-signed-in (which otherwise would be fired as a user-updated event where the date of the last sign-in was changed), etc. My feeling is that even though it would be handy for those subscribers only interested in a very specific change, it would be harder for those services that need to sync whatever happens to the user, as they would have to be subscribed to an increasing number of topics to keep track of all the changes in the user model.

  3. A mix between 1 and 3, where both events user-updated and user-email-updated would be sent when the user updates the email, but just user-updated would be sent if the user changes the profile.

Bustikiller
  • 2,423
  • 2
  • 16
  • 34
  • Option 2 is your best option, business events you can source context from. my 2 cents, happy to discuss further – Sean Farmar Mar 04 '19 at 20:04
  • @SeanFarmar thanks for your comment. The drawback I see here is that for some changes in a model there may be no further action than synchronizing the new value to the rest of the service. I think there could be many changes in the model that need to be synced between services but without relevance enough to own a topic by themselves. Do you have any further idea about how to deal with this? – Bustikiller Mar 06 '19 at 09:48
  • Topic based routing is not a prerequisite for doing event driven systems. I would look at a service bus architecture where routing is pub-sub and decentralised. – tom redfern Mar 07 '19 at 09:36

1 Answers1

1

The way to go is to implement the 2nd option but implement it with a topic hierarchy to allow subscribers to choose the granularity of their interest (as in subscribing to users.* or *.updated or user.actions.login etc. )

Some technologies (e.g. RabbitMQ) has this capability built-in, for others you can implement a topic registry and provide the infrastructure to manage subscriptions yourself

Arnon Rotem-Gal-Oz
  • 25,469
  • 3
  • 45
  • 68