Microservices Architecture

• Inspired by Domain Driven Design. Bounded Context is the word here.
• Microservices is about high decoupling. Expect duplication over reuse.
• It is a distributed architecture. Transactions will always be a challenge.
• Each service should be independent of the others, including data storage.
• Each service represents a domain or subdomain of a business system.
• If the number of calls between two or more services is high, it is common to merge them.
• If you need orchestration between services, avoid the API layer, if you are using one.
• Sidecar is a way to make sure all services have the required operational functions. (forming a Service Mesh)
• The User Interface can go with a Monolithic approach or use Micro frontends
• Orchestration vs Choreography is always a debate in this architectural style.
• For transactions between services, consider the SAGAs pattern.
• Pros: elasticity, evolution, modular, scalability, testability, reliability, and fault tolerance
• Cons: cost, simplicity, and performance