Microservices Architecture
This article is a glossary entry on microservices – including exam questions and tags.
In a Nutshell
Microservices are small, independently deployable services with clearly defined business responsibility. Each service encapsulates its data and communicates via well-defined interfaces.
Compact Technical Description
In microservices architecture, a system is divided into business-aligned services, often along a Bounded Context from DDD. Each service owns its own data model and its own persistence store. Communication is preferably asynchronous via events; for synchronous needs, lightweight APIs like REST or gRPC are used. Deployments are independent; Continuous Delivery enables fast increments. Consistency is usually eventual; distributed transactions are coordinated via Sagas. Observability is mandatory: structured logs, metrics, traces, and correlation IDs are necessary to track distributed calls.
Exam-Relevant Key Points
- Cutting along business domain, one Bounded Context per service, data per service, no shared schema
- Communication styles: asynchronous messaging for decoupling, synchronous used sparingly
- Data consistency: Sagas, Outbox, Inbox, idempotent processing, exactly-once semantics
- Name quality goals: changeability, availability, security, traceability (SLOs)
- Independent repos, build, test, deploy per service, Consumer Driven Contract Tests
- Security aspect: mTLS, OAuth 2/OIDC, Secrets Management, Policy Enforcement, Rate Limiting
- Economics: team autonomy, parallel development, scaling per hotspot, higher operational overhead
- Documentation requirement: C4 Model Level 1-3, interface contracts, ADRs, operations guide, disaster plan
Core Components
- Business cutting, Bounded Context per service
- API Design: resources or RPC, versioning, backward compatibility
- Data per service: independent persistence, migration strategy
- Communication layer: Message Broker, Queue, Stream, Request-Response
- Service Discovery and Routing: API Gateway, Ingress
- Resilience: Circuit Breaker, Timeouts, Retries with Backoff, Bulkheads
- Observability: Logs, Metrics, Tracing, Correlation ID
- Deployment and Infrastructure: Container, Orchestration, IaC, CI/CD
- Security: mTLS, AuthN/AuthZ, Secrets Management, Audit Logging
- Testing approaches: Unit, Integration, Contract Tests, Chaos Engineering, Load Testing
Practical Example
// Saga, Orchestrated: Order process with Order Service, Payment Service, Inventory Service
POST order/create { customerId: 42, items: [{ sku: "A1", qty: 2 }] }
Order Service stores Order status: pending, generates Event: order.created (outbox)
Orchestrator receives order.created, calls Payment Service:
POST payments with Idempotency Key: ord-42
Payment Service authorizes amount, publishes Event: payment.authorized
Orchestrator calls Inventory Service:
POST reservations { orderId: 42, items: ... }
Inventory reserves items, publishes Event: inventory.reserved
Orchestrator sets Order to status: confirmed, publishes order.confirmed
Compensation on inventory.reservation.failed:
- Calls Payment Service: POST payments/refund
- Sets Order to cancelled
Advantages and Disadvantages
Advantages
- Independent deployments, faster changes
- Targeted scaling, better fault isolation
- Technology diversity per service, clear responsibilities
- Team autonomy, parallel development
Disadvantages
- Higher operational complexity
- Distributed debugging, network failures and latencies
- Data consistency must be explicitly modeled
- Demanding observability and security
- Risk of a Distributed Monolith
Typical Exam Questions (with Short Answers)
- Business cutting for microservices? Along a Bounded Context with clear Ubiquitous Language, minimal coupling, maximum cohesion.
- Distributed transactions without Two Phase Commit? Via Saga with orchestration/choreography, idempotent compensation steps, Outbox Pattern.
- Problem with synchronous call chains? Amplify latencies/failures, cascade effects, reduce autonomy. Countermeasures: asynchronous events, Circuit Breaker.
- Data per service in practice? Each service owns its own persistence schema, hides it behind API, integrations via events/APIs.
- Role of API Gateway? Central entry point: routing, authentication, rate limits, observability, protocol translation.
- Traceability across service boundaries? Correlation IDs, distributed tracing, structured logs, consistent propagation across all calls.
- When economically justified? With larger teams and complex domains, when independent deployments justify operational overhead.
- Consistency vs. availability in CAP? Usually higher availability with eventual consistency, local invariants strictly enforced, global via Sagas.