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