1. Microservices Principles
- Single Responsibility — each service owns one business capability and its data.
- Independent Deployability — deploy, scale, and roll back services without coordinating the whole system.
- Decentralized Data — no shared database; each service chooses its own store (polyglot persistence).
- Smart Endpoints / Dumb Pipes — business logic lives in services, not in middleware; messaging infra just routes bytes.
- Design for Failure — retries, circuit breakers, bulkheads, and graceful degradation.
2. Service Decomposition
Bounded Contexts (DDD) — identify language boundaries. "Order" means different things in sales vs. shipping. Each bounded context becomes a candidate service.
- Strangler Fig Pattern — migrate incrementally: route traffic to new microservices while the monolith still handles remaining features. Remove monolith modules one by one.
- Anti-corruption Layer — translate between old monolith models and new service contracts to prevent legacy pollution.
- Tip: Start decomposition with the domain that changes most frequently or needs independent scaling.
3. Communication Patterns
Synchronous vs Asynchronous
- HTTP / gRPC — request-reply; simple but creates temporal coupling. Use for queries needing immediate response.
- Queues / Events (Service Bus, Event Hubs) — decouples sender from receiver; enables retry, replay, and load leveling.
Choreography vs Orchestration
4. CQRS — Command Query Responsibility Segregation
Separate the write model (commands) from the read model (queries). Each can use different stores, schemas, and scaling strategies.
When CQRS helps: read-heavy workloads, different scaling needs for reads vs. writes, complex domain models, or when read projections need denormalized views.
5. Saga Pattern — Distributed Transactions
In microservices there is no global 2PC (two-phase commit). A saga coordinates a sequence of local transactions, each followed by a compensating transaction if a subsequent step fails.
💡 Implement sagas with Azure Durable Functions (orchestration) or Service Bus topics (choreography). Always make compensations idempotent.
6. Sidecar & Ambassador Patterns on AKS
- Sidecar — a helper container in the same pod. Handles cross-cutting concerns (logging, mTLS, config) without changing application code.
- Ambassador — a sidecar that proxies outbound calls, handling retries, circuit-breaking, and protocol translation.
- Dapr (Distributed Application Runtime) — provides building blocks (pub/sub, state, service invocation) as a sidecar on AKS. Swaps infra without code changes.
- Service Mesh (Istio / Linkerd) — injects Envoy proxies as sidecars; delivers mTLS, traffic splitting, observability.
7. Data Patterns
- Database-per-Service — enforces loose coupling; services expose data only via APIs or events.
- Event Sourcing — persist state as an append-only stream of events. Rebuild current state by replaying. Pairs naturally with CQRS.
- Outbox Pattern — write domain event to a local outbox table in the same DB transaction, then a relay publishes it to Service Bus. Guarantees at-least-once delivery without distributed transactions.
- Change Data Capture (CDC) — stream changes from Cosmos DB change feed or SQL CDC to downstream services.
8. Real-World: E-Commerce Microservices on AKS
Scenario
A retailer migrates a .NET monolith (orders, catalog, payments, shipping) to microservices on AKS.
Design Decisions
- Decomposition: Bounded contexts → four services. Strangler fig routes via Azure Front Door; legacy endpoints forwarded to monolith during transition.
- Data: Catalog → Cosmos DB (global reads). Orders → Azure SQL. Payments → event-sourced in Cosmos DB change feed.
- Communication: Synchronous gRPC between Catalog ↔ Orders (low-latency lookups). Async Service Bus topics for order-created, payment-confirmed events.
- Saga: Durable Functions orchestrate Create Order → Reserve Payment → Reserve Inventory → Schedule Shipment with compensations on failure.
- Sidecar: Dapr sidecar handles pub/sub bindings and secret retrieval from Key Vault — no SDK lock-in.
- Observability: Distributed tracing via Application Insights; correlation IDs propagated through Service Bus message properties.
Result
Independent weekly deploys per team, 99.95% availability, and catalog reads scaled to 50K RPS via CQRS read replicas in Redis.
9. Exam Tip
🎯 AZ-305 frequently tests: (1) Why database-per-service — answer: loose coupling and independent scaling. (2) When to use Saga vs. 2PC — answer: Saga in microservices because 2PC doesn't span autonomous services. (3) CQRS justification — answer: separate scaling of reads and writes with different data models.