2

I have a question regarding the architecture of microservices and event sourcing. Imagine that I have the User service and the Franchise service.

In the Users entity on the user service I have an attribute called franchise_id that contains which franchise this user belongs to. When a franchise is created in the franchise service, it emits an event "FranchiseCreated" to which the user service is subscribed and in which the franchise ID is transmitted. Once the user service has consumed the event, it stores it in its database so that when creating a user, it can verify that the franchise id exists without being in the same service.

Example DB

FranchiseService


uuid name
2c094375-84bd-40c5-a644-ce094afc6243 Franchise 1
8584d176-436d-44b4-8d72-d96284777be9 Franchise 2

UserService


uuid name franchise_id
71fa02ff-fbc6-4e8e-b07d-d87c1c2f8f2f User 1 2c094375-84bd-40c5-a644-ce094afc6243
037236c0-e357-4629-96fa-9ccfaa57466e User 2 2c094375-84bd-40c5-a644-ce094afc6243
e08f1de-1583-4795-9485-a366cba612dc User 3 8584d176-436d-44b4-8d72-d96284777be9

My question is the following. Imagine that there comes a day when I have to create a new service for the platform in which it is in the same situation as the user service, for example ... the rebranding service. This service contains the configuration of colors and logos of the franchises and this configuration must be referenced by the ID of the franchise that is in the franchise service. In this case the same thing happens as with the user service, but, since the rebranding service is after the creation of many franchises, I have to copy all the IDs of the franchises from one microservice to another before listening to the FranchiseCreated event.

How is there any way to avoid this?

1
  • I think you're talking about event driven systems and not about event sourcing.
    – pinki
    Aug 3, 2021 at 19:41

2 Answers 2

4

If you introduce a new microservice into an existing system, it will need to be initialized. That's basically unavoidable. You should consider how you want to achieve it:

  • run a special database export/import job to transfer franchise ids, or
  • utilize the existing event handling mechanism and only create artificial FranchiseCreated events, possibly directed at the new service's event queue.

To me, the second solution looks more attractive, especially as it might also be usable to transfer missing franchise ids when the receiving service had an outage.

However, it is entirely possible that you could use something like Kafka to keep all events persistent, so you only need to replay them all into a new service when that service is installed. I have zero experience with that, so hopefully someone more knowledgeable will give a detailed answer covering this approach.

2

A classic problem in event driven systems, "what if I wasn't around when the event happend!?"

Normally I would suggest a secondary GetAll() pull function to allow you to catch up. Hans' answer suggest Kafka, which as as streaming database keeps a copy of every message ever and allows you to choose where you start in the queue.

But here I think you just have a bad design. If you start doing this for everything then every microservice is going to have copies of all the other microservices databases all over the show.

Redesign so that the user service calls the franchise service to do the IdExists check and caches the result if required. Subscribe to the messages for cache update/invalidation purposes.

A new service has an empty cache, but no preloading problem.

micro-services should not be afraid to call each other and the extra round trip time API -> API -> DB vs API -> DB should be insignificant

5
  • 1
    The problem with that is that if the franchise service is down, I cannot create new users from the user service. It is true that if I do as you say to cache the results that I am doing, I will be able to create franchise users that are in cache. but not with new franchises without caching. I am thinking that perhaps the best option is to combine the user and franchise service in the same service and create a new authentication service. In this case, when a new user is created from the franchise service, it will send the username and password to the authentication service. how about this? Aug 3, 2021 at 13:28
  • I would say 1. services should never go down. Its true that you want to be careful about making everything interconnected, but each service should have load-balancing and suitable uptime guarantees. Its no good create user working by itself if the next step fails anyway. 2. It would be even less coupled if you just accepted the franchise id without the check. Presumably the sender has already called the franchise service to get the Id anyway (see point 1 about not worrying if it is down1). Its ok to accept external Ids without checking them in the microservice
    – Ewan
    Aug 3, 2021 at 18:16
  • 3. you could simply handle the failure with a retry or assume exists if service is down. If you are fully event driven, can you simply requeue the create user messages for later processing when the franchise service is back?
    – Ewan
    Aug 3, 2021 at 18:19
  • "I would say 1. services should never go down" - That's screams either over confidence or ignorance to me - I'm not sure which? But, please, please, please - always consider the possibility that a service WILL go down. Netflix designed a whole software product to deal with this exact scenario "Chaos Monkey" because no matter how much you try, its almost inevitable it will happen. Secondly, decouple your services. Dont make direct calls between them and if you must, its better to duplicate data in different services than rely on calling them. Dec 13, 2021 at 7:49
  • @robert. the service should always be up from the codes point of view. The point is to deal with failures at an architecture level with failover/high availablity so you dont have your code peppered with low probablility what if senarios
    – Ewan
    Dec 13, 2021 at 10:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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