Need Microservices? • Ready to go for Microservices? • Advantages and Challenges • Data Consistency in Microservice Architecture • Communication Between Microservices • Demo - Event-Driven Communication 2 / 20
consist of multiple single purpose microservices. A microservice , is a service that independently developable, deployable, scalable and designed as simple as possible. Always remember these 2 principles for your microservices ; - Be fully independent. - Do one thing and do it well. Definition of Microservice Architecture 3 / 20
hype. - Stay away from Hype-Driven Development. - Monoliths are not outdated. - Yes, because our application and code-base are growing day by day. - You need to scale out your entire app or some key functionalities ? - You want to use right tool for the right task, but you can’t ? - You want to be agile, but you can’t ? 4 / 20
DevOps culture and Agile methodologies. - Container Technology and Cloud Provider Expertise - Monitoring & Alerting System - Centralized Logging Infrastructure - Good Communication Between teams. 5 / 20
language, framework, db, etc. ) - Splitting the code-base into small service and teams. ( easy to manage ) - No single point of failure. - Easy and effective scalability. - Easy to understand. ( fast adaptation of new employees ) 6 / 20
Providers, CI-CD pipelines etc. - Integration Test Cost → It’s not easy even in monolith systems. Give a try to CDC testing? - Code Duplication → DRY principle ? - Being Independent → Shared libs, Synchronous communication needs etc. - Defining Boundaries of Microservices → If the two services are communicating intensively, maybe they must be turned into a single service. 7 / 20
can be inconsistent and how do we prevent it ? - How do we manage data consistency in distributed systems ? - Workflow Engine ? A lead actor may cause a tightly-coupled system. - Two-Phase Commit (2PC) ❌ It is a performance killer. - Event-Driven Architecture ✅ - Saga Pattern. Let’s talk about 2PC and Saga. 8 / 20
a coordinator. ( which is a single-point-of-failure ) - Prepare Step ( also known as voting ) - Commit Step 9 / 20 ⚠ Participants keep locks on resources until they receive the voting result from the coordinator.
Saga approach removes the need for 2PC, but also brings new challenges. - In case of failure, all committed transactions must be rollbacked by compensation transactions. - Compensation transactions must be idempotent and cannot be abort. Saga Pattern 10 / 20 image from https://blog.bernd-ruecker.com
domain events for trigger others. As the number of steps increases, the complexity also increases. ⚠ - Orchestration Method An orchestrator tells the services ( participants ) what local transactions to execute. May cause a more tightly-coupled design than Choreography. ⚠ 11 / 20 - You have to manage concurrency and race condition if you implement Saga by yourself. - Or you may want to use a framework such as Masstransit, NServiceBus etc. ⚠
Http - Synchronous ) A microservice makes a real time http request to communicate with another one. - gRPC ( Remote Procedure Call - Synchronous ) High-performance communication framework designed for making RPC calls. - Event-Driven ( Messaging - Asynchronous ) A microservice publishes an event to the message broker. It has no idea about which services are interested in the event. 14 / 20
calls between our services as much as possible. Because ; Http is a synchronous protocol. It violates the ‘independent microservices’ rule. - How can we reduce http calls ? ( if you can’t reduce, do it async. ) Combine heavily communicating microservices. Give a try to Domain-Driven Design approach. ( sharing data across bounded contexts ) 15 / 20
A depends on the data that service B provides, it may store a replica of it to avoid the http request. But this brings a new challenge like syncing data between A and B. Customer Service BasketTable Id CustomerId CreateDate Order Service BasketTable CustomerId Suppose that, Order service validates that customer has a basket on each new order request. Basket doesn’t belong to Order domain. 16 / 20 Eventual consistency based on async communication <= =>
other. - Enables to design a fully-asynchronous, long-running transactions. - Enables high scalability. - Easy to trigger multiple services with single event. 17 / 20 What if service A not only depends on the data but also needs to trigger service B ? Then communication is must, but it doesn’t need to be request / response style.
Service Notification Service RabbitMQ Login Request Command Query Validate Credential Jwt Token 202 Accepted Query Result Command - Token verification is done only by api gateway for each request. - Services can be placed in a private network and accessible by only api’s ip address. Event Event Query 18 / 20 DB DB DB