Chapter 18 Flashcards — Microservices Architecture
flashcards fsa microservices-architecture
What is a bounded context in microservices?
?
A bounded context (from Domain-Driven Design) is a self-contained semantic domain within which a particular model of the business is consistent and complete. In microservices, each service maps to exactly one bounded context — it owns its domain model, its business logic, and its data. The boundary is enforced by the service interface: external consumers see only what the service exposes, never its internal model.
Why does data isolation require each microservice to have its own database?
?
Data isolation prevents re-introducing coupling at the data layer: if Service A reads Service B’s tables directly, a schema change in Service B breaks Service A — coupling is identical to a monolith, but with distributed system overhead. Each service must be the sole authority for its own domain data. This also allows each service to choose the database technology best suited to its domain (relational, document, graph, etc.).
What are the two granularity failure modes in microservices?
?
Too fine-grained → distributed monolith: services have no autonomous business capability; all calls are synchronous across service boundaries; the system has microservices’ operational cost with a monolith’s coupling. Too coarse-grained → mini-monolith: services encompass multiple bounded contexts; multiple teams must coordinate changes; the service becomes a deployment bottleneck. The right size owns a complete, independently deployable domain capability aligned to one team.
What is the sidecar pattern in microservices?
?
The sidecar pattern deploys a separate lightweight process alongside each service instance to handle cross-cutting operational concerns (logging, distributed tracing, service discovery, health checks, circuit breaking, mTLS) on behalf of the service. The service code is unaware of these concerns — it simply makes network calls. The sidecar intercepts all inbound and outbound traffic. This enables consistent operational behavior across services written in different languages without duplicating operational code in each service.
What is a service mesh and what does it provide?
?
A service mesh is a dedicated infrastructure layer — implemented as sidecar proxies (one per service instance) plus a control plane — that handles all service-to-service communication concerns: mTLS (automatic encryption and authentication), load balancing, circuit breaking, distributed tracing, traffic management (canary deployments, A/B testing), and observability metrics. Examples: Istio (feature-complete, complex), Linkerd (lightweight). It replaces ESB cross-cutting concerns as infrastructure without a central bottleneck.
What is the API Gateway pattern and what is its key constraint?
?
An API Gateway is the single entry point for all external clients, handling authentication, rate limiting, routing, request aggregation, and protocol translation. The key constraint: the API Gateway must never contain business logic — it is a dumb pipe for policy enforcement and routing. Business logic in the gateway recreates the SOA ESB antipattern. Examples: AWS API Gateway, Kong, Apigee, Nginx.
What is the Backend for Frontend (BFF) pattern and when is it used?
?
The Backend for Frontend (BFF) pattern creates a separate, purpose-built API gateway for each distinct client type (mobile app, web app, partner API) rather than a single shared gateway. Mobile clients need small payloads; web clients need rich aggregated views; partners need stable versioned interfaces. A single gateway makes trade-offs that satisfy none. Each BFF is owned by the same team as the client it serves. Trade-off: more API surface area to maintain, some code duplication across BFFs.
What is the difference between choreography and orchestration in microservices?
?
Choreography: services react to events independently with no central controller; each service publishes events when it completes its work; no single service knows the full process flow. Pros: high decoupling. Cons: process flow is invisible and distributed, hard to trace and debug, complex failure handling. Orchestration: a central orchestrator service controls the workflow, calling each participant in sequence and handling failures explicitly. Pros: visible process state, explicit compensation logic. Cons: orchestrator is a coupling point.
When should you choose choreography vs. orchestration for a microservices workflow?
?
Choose choreography when: the interaction is simple (2-3 services), adding new consumers is likely, and the domain naturally models as reactive events (e.g., “order placed” triggers notifications, analytics, audit independently). Choose orchestration when: the process is long-running with many sequential steps, failure and compensation logic is complex, explicit process state visibility is required (e.g., a multi-step checkout with payment, inventory, and shipping). Orchestrated sagas are the default recommendation for complex business processes.
What is a SAGA and why does it replace distributed transactions in microservices?
?
A SAGA is a sequence of local transactions (one per service) where each step either succeeds (committing immediately) or triggers a compensating transaction to undo prior steps. It replaces 2-Phase Commit (2PC) because 2PC requires locking resources across all participants simultaneously — making the coordinator a SPOF and bottleneck that defeats independent scalability. SAGAs allow each service to commit locally and independently, with business-level compensation (not database rollback) handling failures.
What is the difference between an orchestrated saga and a choreographed saga?
?
An orchestrated saga uses a dedicated Saga Orchestrator service that manages the workflow — it calls each participant, handles responses, and triggers compensation on failure. Explicit state, easy to visualize, compensation logic is centralized. Risk: orchestrator becomes a coupling point. A choreographed saga has no central controller — each service listens for failure events and publishes compensating events. Fully decoupled, but the saga flow is implicit and distributed, making failure scenarios very hard to reason about and debug.
What are compensating transactions in the SAGA pattern?
?
Compensating transactions are new, forward-moving business operations that undo the business effect of previously committed local transactions when a saga step fails. They are NOT database rollbacks — prior local transactions have already committed and may have been visible to other services. For example: if Payment succeeded but Inventory reservation failed, the compensating transaction for Payment is a refund operation (a new charge-reversal transaction), not a database rollback of the payment record.
What is eventual consistency in microservices and what does it mean for system design?
?
Eventual consistency means that data in different services that is logically related will be consistent only eventually, not immediately. Because each service owns its own database and updates propagate asynchronously via events, there is a window after a write where different services show different views of the world. System design implications: UIs must tolerate brief inconsistency (show “processing” states), write paths cannot assume immediate cross-service consistency, and business workflows that require synchronous consistency must use explicit sagas — not assumed global transactions.
What is CQRS and how does it apply to microservices data topologies?
?
CQRS (Command Query Responsibility Segregation) separates the write model (commands) from the read model (queries). In microservices: write services publish events; a dedicated read model service consumes events and maintains a denormalized view optimized for queries. This enables cross-service data aggregation for reads without cross-service joins on write databases. The read model is eventually consistent. It solves the “how do I query data that spans multiple services?” problem without violating data isolation.
What does “you build it, you run it” mean in microservices culture?
?
“You build it, you run it” (Werner Vogels, Amazon) means the team that builds a service is also responsible for operating it in production — including being on-call. This creates strong incentives: teams directly feel the pain of poor observability, unreliable deployments, and fragile dependencies, and are motivated to design systems that are easy to operate. It is the operational philosophy that makes autonomous microservices teams work in practice.
What is consumer-driven contract testing and why is it important?
?
Consumer-Driven Contract Testing (CDCT) allows API consumers to define their expectations of a service’s API as machine-executable contracts (using tools like Pact). The service provider runs these consumer-defined contracts as part of its own test suite. A service cannot be deployed if it breaks any consumer’s contract. This prevents the “API silently breaks its consumers” failure mode that would otherwise only be caught in integration or production environments.
What are the microservices architectural characteristics ratings?
?
Microservices ratings: Overall agility ★★★★★ (independent per-service deployment), Deployment ease ★★★★☆ (independent but requires DevOps tooling), Testability ★★★★☆ (isolated service testing, complex end-to-end), Performance ★★★☆☆ (network overhead on all calls), Scalability ★★★★★ (per-service independent scaling), Development ease ★★☆☆☆ (distributed system complexity), Simplicity ★☆☆☆☆ (most operationally complex style), Cost ★★☆☆☆ (high infrastructure and DevOps cost).
Why does microservices score only ★★★☆☆ for performance?
?
Microservices scores ★★★☆☆ for performance because every inter-service call is a network call — subject to latency, serialization/deserialization overhead, and all 8 fallacies of distributed computing. Synchronous call chains compound latency additively (A→B→C→D means 4 network hops minimum). In-process calls (as in a monolith) have nanosecond latency; inter-service network calls have microsecond-to-millisecond latency. For high-performance use cases, this overhead is material.
Why does microservices score ★☆☆☆☆ for simplicity?
?
Microservices scores ★☆☆☆☆ for simplicity because it is the most operationally complex architecture style: 50+ independently deployed services, each with its own database, monitoring dashboards, alerting rules, scaling configuration, and deployment pipeline; distributed tracing across service boundaries; contract testing infrastructure; service mesh configuration; saga orchestration for multi-step processes; eventual consistency handling throughout. The individual service is simple; the distributed system as a whole is maximally complex.
What is the “microservices premium” and when does it pay off?
?
The microservices premium (Martin Fowler) is the additional complexity cost of operating a distributed system compared to a monolith — distributed tracing, per-service DBs, contract testing, service mesh, saga orchestration, etc. This premium only pays off when: (1) the team is large enough that independent deployment cadences are a real bottleneck without microservices, (2) scalability requirements are genuinely heterogeneous across domains, and (3) the organization has (or can build) DevOps/SRE capability. Small teams with microservices destroy velocity.
What is a micro-frontend and what challenges does it introduce?
?
A micro-frontend applies the microservices principle to the UI: each service team owns the end-to-end slice of their domain including the frontend components. A shell application provides navigation, auth, and composition; individual teams deploy their domain’s UI independently (using Web Components, Module Federation, or iframe composition). Challenges: UI consistency across teams, shared state management, authentication propagation, performance (multiple JavaScript bundles), and end-to-end testing of the composed application.
What is the domain cluster data topology in microservices?
?
A domain cluster is a data topology where multiple closely related services share the same database server but with strict schema separation — each service owns its own schema. Acceptable when services are in the same domain cluster, schemas are exclusively owned by their respective services, and no cross-schema writes occur. It is a pragmatic stepping stone toward full per-service database isolation when the operational overhead of separate database instances is not yet justified.
When should you NOT use microservices?
?
Do NOT use microservices when: (1) the team is small (<20-30 engineers) without dedicated DevOps capacity — operational overhead consumes all engineering velocity; (2) the domain model is not yet stable — service boundaries drawn before the domain is understood will be wrong, and microservice boundary refactoring is expensive; (3) scalability requirements are uniform — the main benefit is irrelevant; (4) strict synchronous data consistency is required throughout the system; (5) the budget cannot support per-service DBs, Kubernetes, and managed messaging.
What is the key architectural lesson microservices took from SOA’s failure?
?
Microservices adopted “prefer duplication over coupling” as a direct correction to SOA’s “maximize reuse.” Each service duplicates logic and data rather than sharing it — because shared components create coupling that destroys independent deployability. The realization: isolated, duplicated logic is deployable independently; shared logic creates coordination cost that scales with the number of consumers. This is the defining philosophical shift between SOA and microservices.
How does Conway’s Law apply to microservices team structure?
?
In microservices, Conway’s Law is used intentionally: teams are organized one-per-service (or per small service cluster), each cross-functional (dev, QA, ops). The team boundary becomes the service boundary — each team owns their service’s design, deployment, and production operation without coordinating with other teams. A Platform Team provides the infrastructure-as-a-product (Kubernetes, CI/CD, service mesh) that service teams consume. This is the Inverse Conway Maneuver applied at scale.
What are the three main risks of synchronous communication chains in microservices?
?
Synchronous call chains (A→B→C→D) have three main risks: (1) Compounded latency — each hop adds network round-trip time; a 4-hop chain has 4x the minimum latency of one call; (2) Amplified failure probability — if each service has 99.9% availability, a 10-service chain has only ~99.0% end-to-end availability; (3) Temporal coupling — all services in the chain must be simultaneously available; a failure anywhere fails the entire operation with no partial progress.
What is the difference between a message queue and event streaming in microservices?
?
A message queue (RabbitMQ, AWS SQS) provides point-to-point messaging — one sender, one consumer. Messages are consumed and deleted. Used for work distribution and reliable task execution. An event stream (Kafka, AWS Kinesis) provides publish-subscribe messaging — one publisher, many consumers. Events are persisted in a durable log; consumers read at their own pace and can replay from any point. Used for event-driven architectures, CQRS read projections, audit trails, and fan-out scenarios.
Why is distributed tracing essential in a microservices system and how is it implemented?
?
Distributed tracing is essential because a single user request may span 10+ services, producing log entries in 10 different places. Without correlated trace IDs, debugging a 500ms latency spike or a production error requires manually correlating logs across all services — practically impossible at scale. Implementation: each request gets a unique trace ID at the API gateway, propagated via HTTP headers (W3C Trace Context) through every service call. The service mesh (or instrumented SDK) records spans per service. Tools like Jaeger or Zipkin aggregate and visualize the full trace.
What is gRPC and when should it be preferred over REST for microservices communication?
?
gRPC is a binary RPC framework using HTTP/2 and Protocol Buffers. Prefer gRPC over REST for service-to-service communication when: (1) performance matters — binary protocol has much smaller payload size and lower serialization overhead than JSON; (2) strong typing is valuable — Protobuf schemas enforce interface contracts at compile time; (3) streaming is needed — gRPC supports bidirectional streaming natively. REST is preferred when: browser compatibility is needed, the API is publicly consumed, human readability matters, or the team lacks gRPC expertise.
What are the three pillars of microservices observability?
?
The three pillars of microservices observability are: (1) Metrics — quantitative measurements of service behavior (latency percentiles, error rate, throughput, saturation); collected per-service via the service mesh sidecar and aggregated in Prometheus/Grafana; (2) Logs — structured event records per service instance; centralized in Elasticsearch/Loki for correlation across services; (3) Traces — distributed call chains with spans showing latency and errors per service hop; aggregated in Jaeger or Zipkin. All three are required to diagnose production issues in a distributed system.
What is Kubernetes’ role in microservices deployment?
?
Kubernetes is the de facto orchestration platform for microservices: each service runs as a Deployment (with its own Pod spec and replica count), services discover each other via Kubernetes DNS, horizontal scaling is per-service (kubectl scale), rolling deployments enable zero-downtime updates, and the platform abstracts underlying infrastructure. Kubernetes provides the independent deployment and scaling that microservices require — without it, managing 50+ independently deployed services would require manual infrastructure coordination that negates the architecture’s benefits.
What governance mechanisms enforce API contracts between microservices?
?
Key API governance mechanisms: (1) Consumer-Driven Contract Testing (Pact) — consumers define their API expectations; providers run them in CI; deployment blocked if contracts break; (2) API versioning (URL versioning /v1/, header versioning) with formal deprecation periods; (3) Schema Registry (Confluent) for event schemas — enforces backward/forward compatibility; (4) OpenAPI/Protobuf specifications — machine-readable contracts that generate client SDKs and server stubs; (5) Service catalog (Backstage) for discoverability and ownership visibility.
What is the “distributed monolith” antipattern in microservices?
?
A distributed monolith is a system that is architecturally microservices (separate deployable services) but behaves like a monolith in its coupling: services are too fine-grained to have autonomous business capability, all calls are synchronous across service boundaries, services cannot deploy independently (behavioral dependencies prevent it), and every feature change requires coordinating multiple services simultaneously. It has all the operational complexity of microservices with none of the independence benefits. The root cause is granularity that is too fine — services that only make sense together.
Priority: HIGH — core microservices patterns for system design interviews and modern distributed architecture work