Microservices Study Guide

📖 Core Concepts Microservice Architecture – Breaks an app into loosely‑coupled, fine‑grained services that talk over lightweight protocols (e.g., HTTP, messaging). Business‑Capability Focus – Each service owns a single, well‑defined business function (e.g., “order‑processing”). Loose Coupling & Bounded Contexts – Services are isolated; a bounded context is a domain area where the data model is consistent. Ideally one bounded context ⇢ one service. Independence – Services can be developed, deployed, and scaled separately, enabling autonomous teams and continuous delivery. Technology Heterogeneity – Different services may use different languages, databases, or runtimes, chosen to fit the problem best. --- 📌 Must Remember Granularity Decision Factors – Integrators (shared transactions, tightly coupled processes) → combine services; Disintegrators (fault tolerance, independent scaling) → split services. Mapping Rules – One‑to‑One: cleanest boundary, independent scaling. One‑to‑Many: split a bounded context for scalability or ops. Many‑to‑One: combine contexts to reduce operational overhead. Circuit Breaker – Prevents a failing service from dragging the whole system down; used inside cells (logical groups of services). Consumer‑Driven Contract Testing – Verify that a provider’s API satisfies consumer expectations without full end‑to‑end tests. Observability Pillars – Logs, metrics, distributed traces → must be aggregated centrally. --- 🔄 Key Processes Service Design & Granularity Evaluation Gather user requirements → list service responsibilities → weigh non‑functional requirements (latency, fault tolerance). Apply Integrator vs. Disintegrator factors → decide to combine or split. Mapping to Bounded Contexts Identify domain models → define bounded contexts → choose mapping strategy (1‑1, 1‑many, many‑1). Deployment Pipeline (Decentralized CI/CD) Code → unit tests → contract tests → build container image → push to registry → service‑mesh sidecar added → k8s deploy → monitor. Circuit Breaker Operation Call → Success? → reset counter. Failure → increment failure count → if threshold exceeded → open circuit (short‑circuit calls, return fallback). After cooldown → half‑open trial → close on success, stay open on failure. --- 🔍 Key Comparisons Fine‑Grained vs. Coarse‑Grained Services Fine‑Grained: easy to test/deploy, high communication overhead, lower performance. Coarse‑Grained: fewer network hops, better performance, larger codebase, harder to change independently. One‑to‑One vs. One‑to‑Many Mapping 1‑1: clean ownership, simple scaling. 1‑many: better scalability, more operational complexity. Synchronous (REST/HTTP) vs. Asynchronous (Messaging) Sync: simple request/response, higher latency, tighter coupling. Async: decouples producer/consumer, improves resilience, adds eventual‑consistency complexity. --- ⚠️ Common Misunderstandings “Microservices = always faster” – Network latency and serialization can make them slower than in‑process calls. “One service per function” – Over‑splitting leads to service proliferation and management overhead. “All services must use the same protocol” – Heterogeneous protocols are allowed; choose what fits each interaction. “No need for contracts because services are autonomous” – Without contracts, breaking changes silently crash dependent services. --- 🧠 Mental Models / Intuition Cell = “Organ” – Think of a cell as an organ that keeps its own vital signs (circuit breakers, health checks). If one organ fails, the body (system) survives. Bounded Context = “Language” – Each context speaks its own language; translating between them requires a translator (API gateway, event bus). Granularity = “Size of a Lego brick” – Too many tiny bricks → long build time; too few large bricks → inflexible. Find the sweet spot where each brick does one clear job. --- 🚩 Exceptions & Edge Cases Many‑to‑One Mapping is acceptable when: Operational overhead dominates (e.g., limited ops staff). Service boundaries are naturally tight and share a lot of data. Circuit Breaker may be disabled for internal, highly reliable services where latency is critical. Shared Libraries – “Share‑nothing” is ideal, but a common utilities library is permissible if versioned and backward compatible. --- 📍 When to Use Which Choose Synchronous REST when: request‑response latency is low, operation is immediate, and clients need the result instantly. Choose Asynchronous Messaging when: you need decoupling, high throughput, or eventual consistency (e.g., order placed → inventory update). Use Service Mesh if: you have > 10 services, need uniform service discovery, load balancing, and observability without instrumenting each service. Apply Circuit Breaker for: any external call that can fail or become slow; especially for third‑party APIs or high‑traffic internal services. --- 👀 Patterns to Recognize “Multiple small services all calling each other” → likely over‑granular → look for integration points that could be merged. “A single service owns multiple bounded contexts” → potential many‑to‑one → check for data‑sharing violations. Repeated “timeout” errors → missing circuit breaker or retry logic. High latency spikes on a specific endpoint → possible network overhead or synchronous cascade; consider async redesign. --- 🗂️ Exam Traps Distractor: “Microservices always reduce latency.” – Wrong; they add network latency compared to monoliths. Distractor: “One bounded context must map to exactly one microservice.” – Wrong; one‑to‑many and many‑to‑one mappings are valid. Distractor: “Service meshes replace the need for API gateways.” – Incorrect; they complement each other (mesh handles intra‑service traffic, gateway handles external traffic). Distractor: “All inter‑service communication should be HTTP.” – Incorrect; async messaging, gRPC, or GraphQL may be better depending on requirements. ---