A monolith contains
- Routing
- Middleware
- Business Logic
- Database access to implement all features of our app
A single microservice contains
- Routing
- Middleware
- Business Logic
- Database access to implement one feature of our app
- Microservices are basiclly software broken into functional components, components that are independent, autonomous processes and are not dependents on others. You no longer have one huge app and a databases. You have decentralised data management. Each component should be replaceable and upgradable
- Best resource to start with microservices is Martin Fowley :)
- Microservices
- Microservices Guide
Data management between services
- This is the big problem of microservices, and what 90% of this course focuses on
With microservices, we store and access data in sort of strange way. Let's look at
- how we store data: Each service gets its own database (if it needs one)
- how we access it: Services will never, ever reach into another services database
Why Database-Per-Service pattern?
- 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 vs nosql)
Communication Strategies Between Services
- Sync: Services communicate with each other using direct requests
- Async: Services communicate with each other using events
These two serve different purpose.
-
direct HTTP calls create a dependancy between your services, and if so you have to ask yourself if in the end it's not the same service that you artificially split.
-
using event or queues you have to be aware that it may takes some time before the second service has the information available to use.
-
In the end the means of communication describe how close the two service are. In my experience, two services with databases may be used asynchronously because they have their data state. If you have no local database, then you need someone to provide them synchronously. (this is just an simple example, it always depends xD)
-
Event is from source to destination while requests is for destination to source.
-
Request : someone ask for information
-
Event : someone notify information to registered client
Depends on the use case
- Prefer event based when there are more subscribers to be notified of an event
- Prefer direct requests for something like service aggregation
Notes on Sync Communication
| Pro | Con |
|---|---|
| Conceptually easy to understand! | Introduces a dependency between services |
| Service D won't need a database! | If any inter-service request fails, the overall request fails |
| The entire request is only as fast as the slowest request | |
| Can easily introduce webs of requests |
Service D: Code to show products ordered by a particular user Let's refine the exact goal of this service Service D: Given the ID of a user, show the title and image for every product they have ever ordered
| Pros | Cons |
|---|---|
| Service D has zero dependencies on other services! | Data duplication. |
| Service D will be extremely fast! | Harder to understand |