Data management strategies for microservices - 100 Days od CSH #4

You might have taken same CS classes on online courses on networking. Than you want to immerse yourself in JavaScript world. After couple of unslept nights, litters of coffee and dozens of unfinished personal projects you're ready for the next challenges.

The world of application architecture

At this point you see that JavaScript have opened not only frontend development path for you (with all the React,Vue,Angular and you name it possibilities) but also complete fullstack development where you can structure your entire backend API design, routing and db connections on Node servers. You can eventually create start up idea app and see that it needs to scale pretty damn' efficiently. This brings me back to the topic I discussed yesterday - intro into application architecture.

If you decided that microservices are the way you go with your app you may quickly encounter big challenge - data management between each of them. The idea behind this architectural approach is that we want to create independent database per service. How come? - you might immediately ask. So, basically we want each service to run independently of other services. The argument in this case is that our database schema might change unexpectedly or just from the optimization point of view some services might function more efficiently with different types of DB's (sql vs nosql).

You want to keep this independence and for that you have to think about the strategy that would come in handy for your services on how to manage data access in different app workflow scenarios.

Microservices data management strategies

There are two categories of these strategies: sync and async communication.

In sync approach there is just one request call made to end service that communicates with all the concurrent services it needs to gather requested data from. This service make direct requests to these services and when it gathers all the data needed it eventually responds to the initial request.

Pros of this approach:

• conceptually easy to understand
• there is no need for service D to have another data storage

Cons of this approach:

• it introduces a dependency between services
• if any service request fails, the overall request fails
• the entire request is only as fast as the slowest request
• upcoming requests can easily grow to the infinite amount

Second strategy to the rescue! In async approach services communicate with each other using events.

Again there is a single request call made but in this case we emit an event storing relevant information about requested data, which flows to the event bus (more on that in upcoming articles). The event bus than takes that event and sends it to any interested services. The relevant information is stored on dedicated database from which data can but easily retrieved for desired request.

Pros of this approach:

• service D does not have any dependencies on other services
• data access will be extremely fast

Cons of this approach:

• pretty complex approach
• there is data duplication and another db needed

In the upcoming articles I'll be showing code implementation of this async data management strategy approach.

⏬ DAILY CHECK OUT ⏬
According to the work I've done today:

I've practice some Ankies (general stuff about js fullstack),
I've attended holacracy tactical meeting as a secretary,
I've created 1 article on dev.to,
I've spent 6 full 25/5 pomodoro interval sessions following Stephen Grider course on Udemy

Tomorrow I'm going to:

Spend at least 1 full hour our focusing on my project
Spend at least 25 mins preparing flashcards on holacracy topic
Spend at least 25 mins preparing flashcards on fullstack topic
Study at least 20 Anki flashcards
Spend at least 1 hour on Stephen Grider course on Udemy
Read 1 full article on Medium.com
Read book for at least 30 mins - Cut Off the Tension (polish translation: Odetnij napięcie) written by Rebekkah LaDyne

Have a wonderful day! 🔥 See you in the next one 😉