Microservices

This post is a concept guide to microservices architecture – including exam-relevant topics, core components, and key considerations.

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

A system is divided into services organized around business boundaries – often aligned with a Bounded Context (DDD). Each service owns its own data model and persistence layer.

Communication patterns:

• prefer asynchronous via events
• use synchronous sparingly over REST/gRPC

Consistency is typically eventual. Distributed transactions are coordinated using Sagas. Reliable side effects are ensured through Outbox/Inbox patterns and idempotent handlers.

Operationally, CI/CD, container orchestration (e.g., Kubernetes), observability (logs, metrics, traces), and security by default (Zero Trust, mTLS, OAuth/OIDC, secrets management) are essential.

Anti-pattern: distributed monolith (overly tight synchronous chains or shared databases).

Exam-Relevant Points

• Business domain alignment: Bounded Context; data ownership per service; no shared schema
• Async preferred, sync sparing (latency and cascading failures)
• Sagas, Outbox/Inbox, idempotency
• Certification exam: articulate quality goals and SLOs
• Security: mTLS, OAuth/OIDC, secrets, rate limiting
• Economics: autonomy vs. higher operational overhead
• Documentation: C4 (levels 1–3), ADRs, API contracts, operational runbooks

Core Components

1. Bounded Context
2. API design and versioning
3. Data ownership per service
4. Messaging, queues, and streams
5. Service discovery and API Gateway
6. Resilience patterns (timeouts, retries, circuit breakers)
7. Observability and correlation IDs
8. CI/CD and Infrastructure as Code
9. Security (authentication, authorization, secrets management)
10. Testing (contract, chaos, load)

Example: Saga Pattern

Order Service creates Order (pending) + Event (Outbox)
Orchestrator:
- calls Payment Service (with Idempotency Key)
- calls Inventory Service (for reservation)
- confirms Order or compensates (refund/cancel)

Example: E-Commerce Platform as Microservices

User Management (e.g., Java + PostgreSQL)
Product Catalog (e.g., Node.js + MongoDB)
Order Processing (e.g., Python + Message Broker)
Communication: REST + Events

Explanation: Each service maintains its own database, can be scaled and deployed independently, and changes in one service shouldn’t break others (clear versioning and contracts).

Advantages and Disadvantages

Advantages

• Independent deployments
• Per-service scaling
• Better fault isolation
• Team autonomy

Disadvantages

• Higher operational and architectural complexity
• Distributed debugging is harder
• Data consistency must be explicitly modeled

Common Exam Questions (with Brief Answers)

1. How do you establish service boundaries? Along Bounded Contexts (DDD).
2. How do you coordinate distributed transactions? Saga pattern with compensation and Outbox.
3. Why are synchronous chains problematic? Latency and cascading failures.
4. What does “data ownership per service” mean? Each database belongs to one service; access only through APIs or events.

Key Takeaway

Microservices make sense only when you have proper domain boundaries, a solid DevOps platform, and observability/security in place. Otherwise, you end up with a distributed monolith.

Learning Strategy

1. Analyze a 3-service architecture (APIs, events, data ownership).
2. Create a Saga sequence diagram including failure paths.
3. Practice advantages and disadvantages in a comparison table.
4. Avoid shared databases.

Typical Tools in Practice

• Docker / Kubernetes
• OpenAPI/Swagger for API documentation
• Metrics and monitoring (e.g., Prometheus, Grafana)
• Tracing (e.g., Zipkin/Jaeger)

Essential References

1. https://microservices.io
2. https://martinfowler.com/microservices