Microservices Architecture Style (MSA)
Microservice architecture style is about creating smaller services which are:
- Independent & Autonomous
- Loosely coupled and stateless so that can be developed, changed and deployed independently.
- Backward compatible and honor service contract.
- Support concurrent development.
- Technology agnostic.
- High Cohesion
- Focus should be on single thing and having single responsibility.
- Resilient
- Embrace failure and designed for known failure.
- Main reasons for failure are invalid input, exceptions, delay and unavailability of resources.
- Observable
- Centralized monitoring and logging.
- Scalable and Maintainable
- Microservices should be highly scalable and maintainable.
- Automation
- CI, CD along with TDD or ATDD.
Challenges in MSA
- How to identify the number of microservices and define their scopes?
- Use Business technical capabilities map along with DDD patterns and event storming session (for more, click here)
- How to retrieve read data from multiple services?
- API Composition patterns can be used to render UI where aggregated data is required from multiple services.
- CQRS: In this approach, create separate databases/tables for query (GET operations) and commands (POST, PUT, PATCH, DELETE operations) where data can be synchronized by using event driven approach.
- Cold centralized data: Use this approach when real time data is not required. Export “hot data” (transactional data) into “cold data” (de-normalized data) in a centralized database for reporting or analysis, etc. Scheduler/batch job is common synchronization approach.
- How to achieve data consistency?
- Eventual consistency can be think-of instead of true consistency and to achieve it consider event driven communication and publish-subscribe system with Compensating Transaction Pattern.
- Communication across microservices boundaries?
- If the Ordering microservice in turn calls additional microservices using HTTP within the same request/response cycle, you’re creating a chain of HTTP calls. It might sound reasonable initially which may eventually results in chatty I/O.
- Domain related microservices should not know the existence of other services.
- Use only asynchronous interaction for inter-microservice communication, either by using asynchronous message- and event-based communication, or by using (asynchronous) HTTP polling independently of the original HTTP request/response cycle.
- If the Ordering microservice in turn calls additional microservices using HTTP within the same request/response cycle, you’re creating a chain of HTTP calls. It might sound reasonable initially which may eventually results in chatty I/O.