A microservice architecture composes an application from independently deployable services that communicate through interfaces. Its boundaries let different services implement distinct responsibilities while participating in shared request workflows. section 1.4 section 8.1.1
An e-commerce application illustrates the structure: a customer-facing frontend calls checkout, which consults item data, fraud detection, shipping, payment, and other dependencies. Administrative functions and external providers can form separate parts of the wider system. section 8.1.1
Use the architecture as an operational system, not only as a set of deployment units:
- Follow a request across service boundaries when examining behavior, failures, or latency. section 8.1.1
- Instrument services with logs, metrics, and traces, while treating their boundaries as practical teaching categories rather than rigid tool assignments. section 1.4
- Account for deployment and orchestration concerns: the demonstration runs as container images on Kubernetes and can also run with Docker Compose or ECS. section 1.4
Sock Shop and a traced request
Sock Shop combines services written with Spring Boot, Go kit, and Node.js. A separate demonstration architecture uses a frontend calling services A and B, with B calling B0 and B1; an OpenTelemetry Collector ingests generated spans into Jaeger. section 1.4 section 8.2.1
Use the architecture diagram to inspect service-to-service calls and the tracing components surrounding them. section 8.2.1
