Microservice architecture structures an application as loosely coupled, independently deployable services. Each service owns a focused responsibility, data model, and technology stack, then communicates through defined protocols such as REST or gRPC. section 10.1
Compared with a monolithic architecture, this design limits the impact of change. An e-commerce application can separate product and order services, so changing product behavior does not require redeploying order management. section 10.0 section 10.1
The architecture is useful when its operational tradeoffs justify the additional coordination:
- Scale busy services independently: increase product-service capacity for heavy browsing without scaling an unaffected order service. section 10.1.2
- Let teams own and deploy services mostly independently, reducing shared-codebase merge conflicts and deployment coordination. section 10.1.3
- Use asynchronous communication to issue requests to multiple services concurrently and handle grouped failures or slow responses. section 10.1.4
E-commerce storefront
A storefront can divide product, user, and order concerns into separate services, each with its own database. A backend-for-frontend service can aggregate downstream calls, while retries and a circuit breaker help contain service failures. section 10.1 section 10.4
Microservices are not automatically better: monoliths remain simpler to manage for many applications. The choice trades operational simplicity for independent scalability, deployment, team ownership, and technology choice. section 10.1 section 10.4
