Microservices Architecture

This post is a glossary entry on Microservices, including exam questions and key takeaways.

In a Nutshell

Microservices are small, independently deployable services with clearly defined business responsibilities. Each service encapsulates its own data and communicates through well-defined interfaces.

Core Definition

In a microservices architecture, a system is split into business-driven services, often along a Bounded Context from Domain-Driven Design. Each service owns its data model and persistence layer. Communication typically happens asynchronously via events; for synchronous needs, lightweight APIs like REST or gRPC work well. Deployments are independent, enabling Continuous Delivery and rapid increments. Consistency is usually eventual, with Sagas coordinating distributed transactions. Observability is non-negotiable: structured logs, metrics, traces, and correlation IDs are essential to track calls across service boundaries.

Exam-Relevant Highlights

• Service boundaries follow business domains; one Bounded Context per service; data ownership per service; no shared schemas
• Communication patterns: asynchronous messaging for loose coupling; use synchronous calls sparingly
• Data consistency: Sagas, Outbox, Inbox, idempotent processing, exactly-once semantics
• Define quality goals explicitly: changeability, availability, security, traceability (SLOs)
• Independent repositories, builds, tests, and deployments per service; Consumer-Driven Contract Tests
• Security considerations: mTLS, OAuth 2/OIDC, Secrets Management, Policy Enforcement, Rate Limiting
• Economics: team autonomy, parallel development, scaling per bottleneck, higher operational overhead
• Documentation requirements: C4 Model Levels 1–3, interface contracts, ADRs, operational runbooks, disaster recovery plans

Core Components

1. Business domain boundaries, one Bounded Context per service
2. API design: resource-based or RPC, versioning, backward compatibility
3. Data per service: independent persistence, migration strategy
4. Communication layer: message brokers, queues, streams, request-response patterns
5. Service discovery and routing: API Gateway, Ingress
6. Resilience: Circuit Breaker, timeouts, retries with backoff, bulkheads
7. Observability: logs, metrics, tracing, correlation IDs
8. Deployment and infrastructure: containers, orchestration, IaC, CI/CD
9. Security: mTLS, AuthN/AuthZ, Secrets Management, audit logging
10. Testing strategies: 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 saves Order with status: pending, emits 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

Strengths and Drawbacks

Strengths

• Independent deployments, faster changes
• Targeted scaling, better fault isolation
• Technology diversity per service, clear ownership
• Team autonomy, parallel development

Drawbacks

• Higher operational complexity
• Distributed debugging, network failures, and latency
• Data consistency requires explicit modeling
• Demanding observability and security requirements
• Risk of a distributed monolith

Typical Exam Questions (With Brief Answers)

1. How do you define service boundaries in microservices? Along a Bounded Context with a clear Ubiquitous Language, minimizing coupling and maximizing cohesion.

2. How do you handle distributed transactions without Two-Phase Commit? Via Sagas using orchestration or choreography, with idempotent compensating steps and the Outbox Pattern.

3. What’s the problem with synchronous call chains? They amplify latency and cascading failures, reducing service autonomy. Remedy: asynchronous events and Circuit Breakers.

4. How does data-per-service work in practice? Each service owns its persistence schema and hides it behind an API; integrations happen through events and APIs.

5. What’s the role of an API Gateway? Central entry point for routing, authentication, rate limiting, observability, and protocol translation.

6. How do you achieve traceability across service boundaries? Correlation IDs, distributed tracing, structured logs, and consistent propagation throughout all calls.

7. When is this economically justified? With larger teams and complex domains, when independent deployments justify the operational overhead.

8. Consistency vs. availability in CAP? Usually higher availability with eventual consistency; local invariants are strict, global ones coordinated via Sagas.

Key Resources

1. https://microservices.io
2. https://martinfowler.com/microservices
3. https://learn.microsoft.com/azure/architecture/guide/architecture-styles#microservices