Microservice Headfirst
Post Date : 2024-04-19T08:27:33+07:00
Modified Date : 2024-04-19T08:27:33+07:00
Category: systemdesign microservice-architecture
Tags:
In theory, you will split your monolith application in to microservices like this
And the biggest issue we have to face is Data Management Between Services
In this article, we will go through 2 sections to help you dive in deeper in microservice world.
- Microservice Pattern
- Practice: build a shopping website with microservice architecture
Microservice Pattern
Database Per Service
- We want each service to run independently of other services
- Database schema/structure might change unexpectedly
- Some services might function more efficiently with different types of DB’s (sql, non-sql)
Some issues we may got if we don’t apply this pattern
DB for All
Access to another service’s DB
Communication strategies between services
This is our problem, as we do know, each services has their own database if needed. So how do we manage communications between services when they need information from another services.
There are many ways to do that, but in general, they had been organized into 2 categories: sync and async
Sync
Services communicate with each other using direct requests. Whatever protocol or data format.
Async
Services communicate with each other using events.
But looks like it can’t solve the issues that sync strategy introduce.
Command Query Responsibility Segregation
Let’s dive in this example. We have an app with posts and allow user to create comments. Apply this pattern we’ll have the following services. And this is how these service interact when users add their new comments.
But the business logic in the event is too precised. And what if we have a lot of features and services that applied this pattern.
Finally, we may end up with event hell!!!
So the solution is the service should have a deep understanding about the business in the event. So we’ll apply this “Single Responsibility”, in this example CommentService is in charge of comment logic. Query service should only care about the generic event of the comment.
So Query Service only need to listen for update comment, just update
How do we deal with missing events
Your services, somehow, it had been down for a while
You add a new service after your system run for a couple of months or even year
There are 3 options to solve this problem.
Option 1 - Sync Requests
Option 2 - Direct Access
Option 3 - Store Events
Deployment
Docker?
Yes, but not enough. With k8s, things will be more easier.
Quick note for k8s components
Practice
Let assume that we have a monolith application looks like this
Your mission is to refactor this application with microservice architecture. The application has 2 parts: SPA(NextJS) + API (built with your microservices)