Voxxed Days Microservices: Grygoriy Gonchar on Data Consistency
Grygoriy Gonchar talks about the challenge of data consistency when working with microservices applications and solutions from his experience.
Join the DZone community and get the full member experience.Join For Free
Hi Grygoriy, tell us who you are and what lead you into microservices?
For the last years, I've been working as a Software Architect in multiple companies and industries. I'm coming mainly with Java hands-on experience, and besides distributed systems architecture, I also hold a background and interests in software security. Microservices, to me, was always a tool to reduce growing system complexity and I believe that microservices architecture and containerization becomes a de facto standard for complex systems and growing organizations.
What will you be talking about at Voxxed Days Microservices?
While I was working a lot within the financial industry, data consistency was always a challenge with microservices. In financial services such as Kreditech landing platform, many communications reflect real money movements, and frequently, financial data spreads across different domains such as payments, loans, or accounting. Making the data consistent was, for a long time, on my radar, and for years, I was collecting different solutions to the problem. Recently, I've joined eBay Classifieds Group Motors Vertical in Berlin and would be happy to add my eBay experiences to my talk as well. In the end, I want to present all known to me solutions to reach consistent data representation across multiple microservices, such as sagas and compensations, write-ahead log, data reconciliation, change data capture or data replication, and finally, using events as a single source of truth.
One of the first difficult things you need to do when migrating to microservices is to separate your business domain into multiple databases. Do you still see microservice projects that use a single database? If yes, what would be your advice?
Doing a new system from scratch in the microservices approach using a single database/schema instance, I don't see as a reasonable solution. A different situation is migration to microservices. While having an end picture in mind, it's hard to imagine any migration without intermediate steps. I remember a few migrations to microservices that required separation of data. In this case, everything depends on the difference of the end-picture compared to the current situation and how many steps are required to reach the end-picture. While in easy scenarios, data and codebase migration could take a single shot before going live, more complex scenarios required a different approach. We made isolation on the code level first without separating deployments and data. Depending on the ownership of the microservices after deployments migration, data migration was prioritized accordingly. If the same team owns the service data, sharing hurts less than when the data is modified by services owned by different teams. In such cases, doing data migration is one of the most urgent items in the technical debt backlog.
Good, see you soon then
I'm really excited about the new Voxxed Days format in Paris focused on microservices, which is a golden standard for complex systems architecture, so I'm very much looking forward to sharing my knowledge, learning new things, and meeting passionate people around!
Voxxed Days Microservices & DZone, Partnering Up
DZoners! Visit Voxxed Days Microservices here to check out ticket info for the show, and use the DZone reader exclusive code: VXDMS_DZONE to get 20% off for the conference and workshop. Grab those tickets while you can, be sure to say hey to our Zone Leaders—Thomas Jardinet and Chris Ward—if you run into them at the show, and enjoy Paris!
Published at DZone with permission of Antonio Goncalves, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.