From Monolith to Microservices - Migrating a Persistence Layer

Since microservices have become popular, teams are trying to split their monolithic application into a set of small, independent, and highly-scalable microservices. In theory, that often seems like an easy task. You only need to follow the key principles of domain-driven design, identify the bounded contexts in your application, and extract each of them as a microservice.
As so often, the implementation quickly gets much more complicated than it seemed. There are always some use cases that require data from otherwise completely independent services. And some write operations need to ensure data consistency while adding or updating information in multiple services.
In this video, I will show you how to split a monolithic persistence layer into the persistence layers of multiple, independent microservices.
Like my channel? Subscribe!
➜ bit.ly/2cUsid8
Join the free Member Library:
goo.gl/dtyIIC
Read the accompanying post: thorben-jansse...
Want to connect with me?
Blog: thorben-jansse...
Twitter: / thjanssen123
Facebook: / thorbenjanssenofficial
Linkedin: / thorbenjanssen
#Microservices #MonolithToMicroservices #Migration

[@UTUBDZ]

Very interesting topic ! though very complicated to implement. Will appreciate if you would share your experience on that topic on a relative project.

[@TowhidIslam]

Excellent….awesome explanation……❤️👍

[@ramesh_panthangi]

How to manage database transactions between multiple microservices?

[@ztevozmilloz6133]

There is a pattern called saga for this

[@cmdjulian]

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

[@ochmanek]

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.