Thank you for the interesting video Torben! In our application we're having a bunch of different resources already divided into different indipenden packages without dependencies. There is just one exception. We're having the concept of Tags. Every resource is tagged and therefore there exists a foreign key reference in an n:m table to the Tags table. How could I divide tags and other resources in a micro service architecture? Using a different Tags service doesn't feel right because in the case of an delete of a Tag, this change has to be propagated to all resource services. It therefore effectively weakens consistency between my resources and the Tag resource, because there is no database consistency in place anymore. Then I also have to deal with what happens if the call gets lost on the way and this kind of stuff. Do you have some suggestions how to handle that scenario? Thanks in advance Best regards
you should create a microservice that does CRUD operations on TAGs table. You should only modify tags through this microservice. No other microservice can be allowed to touch this part of the database. Do not access the tags through other microservices. Access that fragment of the database only through a single REST endpoint, and remove all other connections from other microservices that can modify this tag. Then make your tag read-only, meaning that you cannot delete it. You may add a new column which will point to the new/updated tag. You can simply travel all the way to the next reference everytime, like in a linked list. This is the only reasonable solution. You need to trade efficiency here. Keeping everything in one place, just to be able to join them with SQL is an overkill. You can do this if the efficiency is bad, but before you do, you should split this functionality and search (select the most up-to-date tag of the one that was used, or deleted) every time. So instead of propagating changes to all microservices, you should always select the tag in a central microservice of a tag and that microservice will tell you if it still exists or not. Do not update all references, simply update it or delete it in one place and let others ask for it. Unfortunately you need to always check if a newer tag exists. I hope this helps.
Very interesting topic ! though very complicated to implement. Will appreciate if you would share your experience on that topic on a relative project.
How to manage database transactions between multiple microservices?
There is a pattern called saga for this
Thank you for the interesting video Torben! In our application we're having a bunch of different resources already divided into different indipenden packages without dependencies. There is just one exception. We're having the concept of Tags. Every resource is tagged and therefore there exists a foreign key reference in an n:m table to the Tags table. How could I divide tags and other resources in a micro service architecture? Using a different Tags service doesn't feel right because in the case of an delete of a Tag, this change has to be propagated to all resource services. It therefore effectively weakens consistency between my resources and the Tag resource, because there is no database consistency in place anymore. Then I also have to deal with what happens if the call gets lost on the way and this kind of stuff. Do you have some suggestions how to handle that scenario?
Thanks in advance
Best regards
you should create a microservice that does CRUD operations on TAGs table. You should only modify tags through this microservice. No other microservice can be allowed to touch this part of the database. Do not access the tags through other microservices. Access that fragment of the database only through a single REST endpoint, and remove all other connections from other microservices that can modify this tag. Then make your tag read-only, meaning that you cannot delete it. You may add a new column which will point to the new/updated tag. You can simply travel all the way to the next reference everytime, like in a linked list. This is the only reasonable solution. You need to trade efficiency here. Keeping everything in one place, just to be able to join them with SQL is an overkill. You can do this if the efficiency is bad, but before you do, you should split this functionality and search (select the most up-to-date tag of the one that was used, or deleted) every time. So instead of propagating changes to all microservices, you should always select the tag in a central microservice of a tag and that microservice will tell you if it still exists or not. Do not update all references, simply update it or delete it in one place and let others ask for it. Unfortunately you need to always check if a newer tag exists. I hope this helps.