96 Microservices Interview Questions and Answers (2026)

The core trade-off is simplicity vs. independence: a monolith is simpler to build, test, and run but couples the whole team and codebase; microservices grant independent scaling and deployment at the cost of distributed-systems complexity.

• Deployment and release:

  • Monolith: one deployable, one pipeline, but any change redeploys everything.

  • Microservices: deploy services independently, but need versioning and coordination.

• Scaling:

  • Monolith scales as a whole unit; you replicate the entire app even to scale one hot path.

  • Microservices scale hot services independently, saving resources.

• Team autonomy: Microservices let teams own services and choose their own tech and cadence; monoliths force shared coordination.

• Consistency and transactions: Monolith gets ACID transactions across a single DB; microservices force eventual consistency and patterns like saga.

• Operational cost: Monolith is cheap to operate and debug; microservices demand mature CI/CD, observability, and orchestration.

A microservices architecture is a set of small, independently deployable services each owning a business capability and its data, communicating over the network, whereas a monolith is one deployable unit sharing a single codebase and database.

• Independent deployability: Each service ships on its own cadence; a monolith redeploys as a whole.

• Bounded around business capability: Organized by domain (from Domain-Driven Design), not by technical layer.

• Decentralized data: Database-per-service vs. the monolith's single shared schema; leads to eventual consistency.

• Independent scaling: Scale only the busy services rather than the whole application.

• Technology heterogeneity: Each service can pick its own language and datastore; a monolith is one stack.

• Fault isolation: One service failing can be contained; in a monolith a bad module can crash the whole process.

• Cost: Network communication, distributed transactions, and operational overhead the monolith avoids.

Independent scaling means each service is deployed as its own process (typically containers behind a load balancer) and can be replicated to more instances based only on its own load, without touching other services. This targets resources precisely instead of duplicating the entire application.

• Per-service replication:

  • An orchestrator (e.g. Kubernetes) runs N instances of a hot service and 1 of a quiet one, routing traffic across replicas.

  • Autoscaling can trigger on CPU, memory, or custom metrics like queue depth or request latency.

• Monolith scaling is all-or-nothing: To handle load in one module you must clone the whole application, wasting resources on components that aren't the bottleneck.

• Advantages of independent scaling:

  • Cost efficiency: spend compute only where demand actually is.

  • Right-sized resources: a CPU-bound service and a memory-bound service can run on different instance types.

  • Isolation: scaling (or a load spike) in one service doesn't consume capacity needed by others.

• Caveat: Shared downstream dependencies (a single database, third-party API) can become the real bottleneck, so scaling the stateless tier isn't enough by itself.

An API Gateway is a single entry point for clients that routes requests to backend services while handling cross-cutting API concerns (auth, rate limiting, aggregation). A load balancer only distributes traffic across instances; the gateway operates at the application/API layer and does much more than balance.

• What an API Gateway does:

  • Routing: maps public paths to internal services.

  • Cross-cutting concerns: authentication/authorization, rate limiting, TLS termination, request/response transformation, caching, logging.

  • Aggregation: can compose multiple service calls into one client response.

• What a load balancer does:

  • Distributes connections/requests across instances of a service based on an algorithm and health checks.

  • Typically L4 (TCP) or L7 (HTTP) but content-agnostic about business/API semantics.

• Key difference:

  • A gateway is API-aware and policy-rich (one entry per API surface); a load balancer is a traffic distributor.

  • They coexist: a gateway routes to a service, and a load balancer spreads that traffic across its instances (gateways often embed LB internally).

Containers package a service with its dependencies into a single portable, isolated unit, which maps almost perfectly onto the microservices ideal of small, independently deployable services. Each service ships as its own image and runs consistently anywhere.

• Isolation matches service boundaries: Each service gets its own runtime, libraries, and language version without conflicting with others.

• Independent deployability: You build, version, and deploy one service's image without touching the rest.

• Consistency across environments: The same image runs on a laptop, CI, and production, killing "works on my machine" issues.

• Fast, elastic scaling: Containers start in seconds, so orchestrators can scale individual services up and down cheaply.

• Ecosystem fit: Standard images (Docker) plug directly into orchestrators (Kubernetes) for discovery, health checks, and scaling.

A container orchestrator automates deploying, running, scaling, and healing containerized services across a cluster of machines. You declare the desired state and it continuously works to make reality match, so operators don't manage individual containers by hand.

• Declarative desired state: You say "run 5 replicas of this image"; the orchestrator reconciles continuously toward that.

• Scheduling: Places containers onto nodes based on resources and constraints.

• Self-healing: Restarts crashed containers and reschedules them when a node dies.

• Scaling: Scales replicas up/down, manually or automatically based on load.

• Networking and discovery: Gives services stable names/IPs, load balances across instances, and manages rollouts.

• Example: Kubernetes is the de facto standard here.

A retry reattempts the same failed operation hoping it succeeds this time; a fallback abandons the failing operation and returns an alternative result. Retry pursues the correct answer; fallback accepts a degraded-but-acceptable one.

• Retry:

  • Assumes the failure is transient and repeating the call will eventually work.

  • Adds latency and load; must be bounded and used on idempotent operations.

• Fallback:

  • Provides a substitute when the operation fails: cached data, a default value, an empty list, or a simpler alternate path.

  • Enables graceful degradation so the user still gets a usable response.

• How they combine: Typical chain: try the call, retry a couple of times on transient errors, and if it still fails (or the circuit is open), invoke the fallback.

You track a request across services with distributed tracing: a Correlation ID (a unique identifier generated at the entry point) is attached to the request and propagated through every downstream call, so all logs and spans for that one user action can be stitched together. It's the thread that lets you follow a single journey through ten services.

• Correlation ID basics:

  • A unique ID (often a UUID) created at the edge (API gateway or first service) if the client didn't send one.

  • Passed on every hop, typically in a header like X-Correlation-ID or via W3C traceparent.

• Propagation: Forward it on HTTP calls and message headers; include it in every log line so logs can be filtered by that one ID.

• Tracing vs correlation:

  • A trace ID identifies the whole request; span IDs identify each service's unit of work, forming a parent/child tree of timing.

  • Correlation ID is the simpler logging-oriented case; full tracing (OpenTelemetry, Jaeger, Zipkin) adds latency and dependency visualization.

• Tooling: Use OpenTelemetry to auto-inject and propagate context, and a centralized log/trace store (ELK, Jaeger) to query by ID.

• Why it matters: Without it, debugging a failure means guessing which of ten services' interleaved logs belong to your request.

In a monolith a single request lives in one log stream on one machine; in microservices a single request touches many independently-deployed services on many hosts, so logs scattered per-instance are useless without being collected, correlated, and searchable in one place.

• Logs are spread across services and instances: One user action produces log lines in several services; you can't reconstruct it by SSHing into each box.

• Instances are ephemeral: Containers restart and scale away, taking local log files with them, so logs must be shipped off-host to survive.

• Correlation is required: A propagated correlation/trace ID lets you filter every service's logs for a single request in one query.

• Typical solution: Ship structured logs to a central store (ELK/EFK, Loki, cloud logging) so you get unified search, retention, and alerting.

Health checks are endpoints (or probes) a service exposes so the orchestrator can programmatically ask whether it is alive and ready. They enable self-healing because the orchestrator acts on the results automatically: restarting wedged instances and routing traffic only to healthy ones, with no human intervention.

• What they are:

  • Usually HTTP endpoints like /healthz and /ready that return a status code the platform polls periodically.

  • Kinds: liveness (is the process healthy?), readiness (can it serve now?), startup (has it finished booting?).

• How they drive self-healing:

  • Failing liveness triggers an automatic restart of the container.

  • Failing readiness removes the instance from load-balancer endpoints until it recovers.

  • Combined with replica counts, the orchestrator reschedules and maintains desired healthy capacity.

• Good practice: Keep liveness dependency-free; put dependency checks in readiness so a downstream outage doesn't cause restart storms.

Recommend against microservices when the added distributed-systems complexity outweighs the benefits: for new projects with unknown domains, small teams, or no operational maturity, a monolith is almost always the better start.

• The domain is not yet understood: Service boundaries are guesses early on; splitting wrong is expensive to fix, so keep boundaries cheap to move inside a monolith.

• Small team or startup: You pay coordination and operational overhead you don't have people for; velocity drops instead of rising.

• No operational maturity: Microservices assume CI/CD, containerization, monitoring, and distributed tracing; without them you inherit pain with no payoff.

• Low scale or simple requirements: If the app has modest load and no parts that scale independently, a monolith is cheaper and simpler.

• Rule of thumb: Start with a well-modularized monolith and extract services later when real scaling or team-autonomy pressures appear.

Both decompose applications into services, but they differ in granularity, sharing, and integration: SOA is enterprise-wide with shared infrastructure and heavy middleware, while microservices are fine-grained, independently deployable, and favor lightweight communication with decentralized data.

• Communication:

  • SOA often uses a smart Enterprise Service Bus (ESB) with orchestration logic in the middleware.

  • Microservices prefer 'smart endpoints, dumb pipes': plain REST/gRPC or messaging with no central bus.

• Data ownership:

  • SOA services frequently share a database or common data models.

  • Each microservice owns its own private data store (database-per-service).

• Granularity and scope: SOA is enterprise-scale reuse of coarse services; microservices are small, single-responsibility, bounded-context services.

• Governance: SOA tends toward centralized governance and standards; microservices favor decentralized, team-owned decisions.

You move to microservices mainly for team and scaling independence at large scale; you keep a monolith when the team is small, the domain is still evolving, or the simplicity is worth more than independent deployment.

• Drivers toward microservices:

  1. Team autonomy: many teams stepping on each other in one codebase; independent services reduce coordination.

  2. Independent scaling: some components need far more resources than others.

  3. Independent deployment: need to release parts frequently without redeploying everything.

  4. Fault isolation and technology diversity for specific workloads.

• When a monolith is better:

  1. Small team where coordination cost is low anyway.

  2. Early-stage or unclear domain where boundaries will shift.

  3. Limited operational maturity (no strong CI/CD or observability).

  4. Simpler debugging, ACID transactions, and lower infra cost matter most.

• Pragmatic path: Start with a modular monolith and extract services along proven seams as pressures emerge.

Both break an application into small independent units, but they differ in granularity and operational model: a microservice is a long-running, self-managed service you deploy and scale, while a serverless function is an event-triggered, stateless unit the platform runs and scales for you, billed per execution.

• Unit and lifecycle:

  • Microservice: a running process/container you keep alive and operate.

  • FaaS: a function invoked on an event, spun up and torn down by the platform (e.g. AWS Lambda).

• Scaling and cost:

  • Microservices scale via instances you manage; you pay for running capacity.

  • Serverless scales to zero and per-request automatically; you pay only for execution time.

• State and startup: Functions are stateless and can suffer cold starts; microservices keep warm state and connections.

• Choose serverless when: Event-driven, spiky, or infrequent workloads where low ops and pay-per-use win.

• Choose microservices when: Steady high traffic, long-running processes, low-latency needs, or you want control over runtime and avoid vendor lock-in.

• Not exclusive: Many systems mix both: core microservices plus functions for glue and event handling.

'You build it, you run it' means the team that develops a service also operates it in production: they own its full lifecycle including on-call, monitoring, and incidents. It closes the gap between developers and operators so the people who wrote the code feel its production consequences directly.

• Full lifecycle ownership: One team designs, codes, deploys, monitors, and is paged for the same service, rather than tossing it over a wall to a separate ops team.

• Feedback loop tightens: Developers who carry the pager write more resilient, observable code because they bear the operational pain of bad decisions.

• Autonomy and accountability: Teams choose their own tech, deploy on their own schedule, and are accountable for SLOs, which fits the decentralized nature of microservices.

• Operational demands change:

  • Requires investment in observability, dashboards, alerting, and self-service platforms so teams can actually run what they build.

  • Culture shift: DevOps mindset, blameless postmortems, and shared on-call responsibility.

Debugging is harder because a single user request fans out across many independently deployed services, networks, and datastores, so there is no single stack trace or process to inspect. Failures are partial, asynchronous, and often non-deterministic.

• No single call stack: A request crosses process and network boundaries, so state and logs are scattered across many machines instead of one memory space.

• Partial and transient failures: The network can be slow, drop, or duplicate calls; a bug may appear only under specific timing or load, making it hard to reproduce.

• Emergent behavior: Problems arise from interactions (retries causing cascades, cyclic dependencies) that no single service's code reveals.

• Correlating events is nontrivial: Without shared context you can't easily tie together the log lines from each service for one request.

• Mitigations: Distributed tracing with a propagated correlation/trace ID (e.g. OpenTelemetry), centralized structured logging, and metrics/dashboards to reconstruct request flow.

A Bounded Context is a DDD concept: an explicit boundary within which a particular domain model and its terms (the ubiquitous language) apply consistently. It's the primary guide for microservice boundaries because a service typically owns exactly one bounded context and its data.

• Language consistency inside the boundary: The same word can mean different things in different contexts: 'Customer' in Sales differs from 'Customer' in Support, and each context models it its own way.

• Model isolation: Each context has its own internal model and data, avoiding one bloated shared model that couples everything together.

• Maps to service boundaries:

  • Aligning a service with a bounded context gives high cohesion inside and clear, contract-based interfaces between services.

  • Relationships between contexts are described with a context map (e.g. customer/supplier, anti-corruption layer).

• Why it matters: Boundaries drawn on business meaning rather than technical layers produce services that change independently and rarely leak across the boundary.

Conway's Law observes that organizations design systems that mirror their own communication structures. In microservices this means your service boundaries will end up reflecting your team boundaries, so you should organize teams to match the architecture you want (the 'Inverse Conway Maneuver').

• The core observation: If four teams build a compiler, you get a four-pass compiler: architecture follows org chart.

• Why it matters for microservices:

  • Independent, loosely coupled services need independent, loosely coupled teams; tightly coupled teams tend to produce tightly coupled services.

  • Cross-team coordination cost shows up as chatty or brittle service interfaces.

• Inverse Conway Maneuver: Deliberately shape teams (small, autonomous, capability-aligned) so the desired architecture emerges naturally.

• Practical implication: Align each team with a bounded context and give it full ownership, so team autonomy and service autonomy reinforce each other.

A shared library reduces duplication and enforces consistency but couples services to a common version and release cadence; duplication keeps services independent at the cost of maintaining the same logic in multiple places. Choose based on how stable and how business-specific the code is.

• Shared library: pros:

  • Single source of truth: fix a bug once, consistent behavior everywhere.

  • Great for stable, generic code (serialization, auth, telemetry).

• Shared library: cons:

  • Coupling: a breaking change can force many services to upgrade and redeploy together.

  • Can become a dumping ground that quietly ties services to each other's business rules.

• Duplication: pros:

  • Full independence: each service evolves and deploys on its own.

  • Good when logic is likely to diverge, or is small and cheap to copy.

• Duplication: cons: Bug fixes and changes must be applied in every copy; risk of drift.

• Rule of thumb: Share stable technical code; duplicate (or keep local) volatile, business-specific code. Prefer a little duplication over the wrong abstraction.

Add it to an existing service if it belongs to the same bounded context and shares its data and lifecycle; carve out a new service only when it represents a distinct capability with independent scaling, deployment, or team ownership needs. Default to the existing service until there is a concrete reason to split.

• Signals it belongs in an existing service:

  • It operates on the same data/aggregates and would otherwise need chatty cross-service calls or shared tables.

  • It's part of the same business capability and changes together with existing logic.

  • It's small: a new service's operational overhead outweighs the benefit.

• Signals it deserves a new service:

  • It's a separate bounded context with its own model and language.

  • It has different scaling or availability needs (e.g. CPU-heavy vs. I/O-heavy).

  • It has an independent deploy cadence or a different owning team.

  • It requires technology or data-store isolation.

• Caution: Premature splitting creates distributed monoliths; you can extract later once boundaries are clear.

Synchronous calls give an immediate response and simple request/reply semantics but couple caller and callee in time (both must be up); asynchronous messaging decouples them and improves resilience and scalability at the cost of complexity and eventual consistency. Pick by whether the caller truly needs an answer now.

• Synchronous (REST/gRPC):

  • Pros: simple mental model, immediate result, easy to trace and debug.

  • Cons: temporal coupling (callee must be available), latency adds up in chains, failures cascade without circuit breakers.

  • Use when: the client needs the response to proceed (queries, user-facing reads).

• Asynchronous (message/event-driven):

  • Pros: loose coupling, buffering absorbs load spikes, better fault tolerance, natural fan-out to many consumers.

  • Cons: eventual consistency, harder debugging/tracing, need to handle idempotency, ordering, and duplicate delivery.

  • Use when: fire-and-forget work, event notifications, long-running processes, or decoupling producers from consumers.

• Practical guidance: Many systems mix both: sync for queries, async for state-changing workflows (e.g. Saga via events).

Choose gRPC for internal service-to-service communication when you want high performance, strict contracts, and streaming: it uses HTTP/2 and Protobuf binary serialization, which is faster and more compact than JSON over HTTP/1.1.

• When gRPC shines:

  • Low latency, high throughput internal calls where binary encoding and multiplexed HTTP/2 connections matter.

  • Strong, versioned contracts: .proto files generate typed clients/servers across languages.

  • Streaming needs: client, server, or bidirectional streaming.

  • Polyglot environments where code generation keeps clients in sync.

• When REST is still better:

  • Public/external APIs and browser clients (gRPC needs gRPC-Web plus a proxy).

  • Human-readable payloads and easy debugging/curl-ability are priorities.

  • Broad tooling and caching over standard HTTP.

• Trade-off: gRPC adds tooling and observability complexity (binary is opaque), so reserve it for internal hot paths where its performance and contracts pay off.

Publish/subscribe is a messaging pattern where producers (publishers) emit events to a topic without knowing who consumes them, and consumers (subscribers) receive events they care about without knowing who produced them: a message broker sits in between and decouples both sides.

• How it works:

  • A publisher sends an event to a named topic/channel; subscribers register interest in that topic and get a copy of each matching event.

  • The broker (Kafka, RabbitMQ, SNS/SQS) handles routing, fan-out, and delivery.

• Why it produces loose coupling:

  • Location decoupling: neither side knows the other's address or identity.

  • Temporal decoupling: subscribers need not be online when the event is published (broker buffers).

  • Cardinality decoupling: one event can fan out to many subscribers; new consumers can be added without touching the publisher.

• Microservices benefit: Services evolve and scale independently; an order service just emits OrderPlaced and billing, inventory, and email react on their own.

• Trade-offs: Harder to trace flows and debug; eventual consistency; the broker becomes critical infrastructure to make highly available.

Point-to-point delivers a message to exactly one consumer (a queue with competing consumers), while pub/sub broadcasts each message to all interested subscribers (a topic). Both can run on a broker; the distinction is the delivery semantics, not just the presence of a broker.

• Point-to-point (queue):

  • One message is consumed by one receiver even if many workers listen (competing consumers).

  • Ideal for work distribution and load-leveling: e.g. a task queue where any free worker processes the next job.

• Broker-based pub/sub (topic):

  • Every subscriber gets its own copy of each event (fan-out).

  • Ideal for event notification where multiple services react to the same fact independently.

• Coupling and knowledge: Point-to-point often implies the sender targets a specific queue/consumer role; pub/sub publishers are unaware of subscribers entirely.

• In practice: Systems mix both: fan-out an event to a topic, then each subscriber's queue distributes work across its own instances (e.g. Kafka consumer groups, SNS to SQS).

Load balancing spreads requests across the healthy instances of a service, and it depends on service discovery to know which instances currently exist: discovery supplies the live address list, and the balancer picks one per request.

• Server-side load balancing:

  • A dedicated component (NGINX, cloud ELB, gateway) sits in front; clients hit one virtual address and it forwards to a backend instance.

  • The balancer is populated from discovery (or health-checks its pool) to add/remove instances.

• Client-side load balancing:

  • The caller queries the registry (Eureka, Consul), gets the instance list, and picks one itself (e.g. Ribbon, gRPC's built-in balancer).

  • Avoids an extra network hop but pushes logic into clients.

• Common algorithms: Round-robin, least-connections, weighted, and consistent hashing (for sticky/session affinity).

• Interaction with discovery: Instances register on startup and deregister/expire on shutdown or failed health checks; the balancer must react quickly so traffic stops hitting dead instances.

Backend-for-Frontend is a pattern where you build a separate, dedicated backend (gateway) for each type of client, so each frontend gets an API tailored to its exact needs instead of sharing one generic API. It solves the problem that mobile and web clients have very different data, payload, and interaction requirements.

• The problem it solves:

  • A single general-purpose API forces mobile clients to over-fetch (wasting bandwidth/battery) or make many round trips.

  • Web and mobile need different aggregations, field sets, and response shapes; one API becomes bloated trying to serve all.

• How BFF works:

  • Each client type (iOS, Android, web) gets its own BFF that calls downstream microservices and shapes responses for that client.

  • The BFF owns client-specific aggregation, formatting, and orchestration logic.

• Benefits: Teams owning a frontend can evolve their BFF independently; smaller, optimized payloads; cleaner separation of concerns.

• Trade-offs: More services to maintain and potential logic duplication across BFFs; keep shared logic in downstream services.

The Sidecar pattern deploys a helper process/container alongside the main application (in the same pod/host) to handle cross-cutting concerns, so the application code stays focused on business logic. The sidecar shares the app's lifecycle and network namespace but runs as a separate process.

• Core idea: Like a motorcycle sidecar: attached to the main service, deployed and scaled with it, but isolated as its own process.

• What it offloads:

  • Networking (mTLS, retries, routing), observability (metrics, tracing, logging), config, and secrets.

  • The app talks to the sidecar over localhost; the sidecar handles the concern transparently.

• Why it's valuable:

  • Language-agnostic: the same sidecar works for services written in any language (no shared library needed).

  • Independent upgrades: update the sidecar without touching app code.

• Canonical example: The Envoy proxy injected next to each service in a service mesh; also log shippers and config-reloaders.

Service Discovery is the mechanism by which services find each other's current network locations automatically, instead of relying on hardcoded IPs. It's essential in cloud-native environments because instances are ephemeral: they scale, restart, and move constantly, so their addresses change frequently.

• Why it's needed:

  • Autoscaling, container orchestration, and failures mean IPs/ports are dynamic and unpredictable.

  • Static config can't keep up; callers need to resolve a logical service name to a live instance at runtime.

• How it works:

  • A service registry stores instance locations; services register on startup and deregister/expire via health checks.

  • Callers query the registry to get healthy instances before making a request.

• Two models:

  • Client-side: the caller queries the registry and load-balances itself (e.g. Eureka, Consul).

  • Server-side: a router/load balancer queries the registry and the client just hits a stable endpoint (e.g. Kubernetes Services via DNS).

• Tools: Consul, etcd, Eureka, and Kubernetes' built-in DNS-based discovery.

Because service instances come and go (scaling, failures, redeploys) and get dynamic IPs, services can't hardcode addresses; they rely on service discovery backed by a registry. The key distinction is who does the lookup and load balancing: the client or an intermediary.

• The problem: Instances are ephemeral with changing network locations, so static config breaks quickly.

• Client-side discovery:

  • The client queries the registry, gets the list of instances, and picks one itself (load balances).

  • Pros: fewer network hops, smart client-side balancing. Cons: discovery logic in every client/language.

  • Example: Netflix Eureka with Ribbon.

• Server-side discovery:

  • The client calls a fixed endpoint (load balancer/router) that queries the registry and forwards the request.

  • Pros: clients stay dumb, logic centralized. Cons: extra hop, the router must be highly available.

  • Example: Kubernetes Service + kube-proxy/DNS.

• Communication styles either way: Synchronous (REST/gRPC) for request-response, asynchronous (message broker) for event-driven decoupling.

An API Gateway is a single entry point that sits between clients and services, handling cross-cutting concerns and routing. A BFF is a specialized gateway: instead of one generic gateway for everyone, you build a tailored gateway per client type (web, mobile, etc.).

• What an API Gateway does:

  • Routing requests to the right service, plus cross-cutting concerns: authentication, rate limiting, TLS termination, request aggregation, caching.

  • Shields clients from internal topology and lets services change without breaking callers.

• The problem BFF solves: A single generic gateway becomes a compromise: a mobile app needs lean payloads while a web app needs richer data, and one API can't serve both cleanly.

• How BFF differs:

  • One gateway per frontend, each shaped to that client's exact needs (fields, aggregation, chattiness).

  • Owned by the frontend team, so it can evolve at the UI's pace.

  • Trade-off: more gateways to maintain and some duplicated logic across BFFs.

Both fan out to several downstream services, but aggregation at the gateway happens at the edge for a client's convenience, while a service calling multiple services is internal business orchestration. The difference is location, purpose, and coupling.

• Gateway aggregation:

  • Lives at the edge; combines responses so the client makes one call instead of many (reduces chattiness/latency for remote clients).

  • Should stay thin: mostly composition, no business logic or domain decisions.

• Service-to-service orchestration:

  • A service calls others to fulfill its own business logic (a workflow it owns).

  • Belongs to a domain and can enforce rules, transactions/sagas, and consistency.

• Why the distinction matters:

  • Putting business logic in the gateway makes it a bloated bottleneck and a shared point of coupling.

  • Rule of thumb: gateway = presentation/composition for clients; service = ownership of a business capability.

A service registry is a live database of available service instances and their network locations. Instances register when they come up, are discovered by callers, and are removed automatically when health checks fail, so traffic only goes to healthy endpoints.

• Registration:

  • Self-registration: the instance registers itself on startup (host, port, metadata) and deregisters on shutdown.

  • Third-party registration: a separate registrar/orchestrator watches instances and registers them on their behalf.

• Health checks:

  • Heartbeats: the instance periodically renews its lease; missing renewals mark it expired.

  • Active probes: the registry calls a /health endpoint to verify liveness.

• Deregistration: On graceful shutdown the instance deregisters; on failure the expired lease removes it so callers stop routing there.

• Examples: Consul, Eureka, etcd, and Kubernetes' built-in endpoints.

The Circuit Breaker wraps calls to a remote dependency and stops calling it once failures cross a threshold, giving the failing service time to recover and preventing the caller from wasting resources on doomed requests. Like an electrical breaker, it "trips" to protect the system.

• Why it's used: Fail fast instead of piling up requests on a broken/slow dependency, avoiding cascading failures and resource exhaustion.

• The three states:

  1. Closed: normal operation, calls pass through; failures are counted.

  2. Open: threshold exceeded, so calls are rejected immediately (fail fast) for a cooldown period, often returning a fallback.

  3. Half-Open: after the timeout, a few trial calls are allowed; if they succeed it goes back to Closed, if they fail it returns to Open.

• Common companions: Timeouts, retries (with backoff), and fallbacks, e.g. via Resilience4j.

Idempotency means processing the same request or event multiple times produces the same result as processing it once. It is critical in event-driven systems because messaging guarantees are usually at-least-once, so duplicates are inevitable and consumers must handle them safely.

• Definition: An operation is idempotent if applying it N times equals applying it once (e.g. "set balance to 100" vs "add 100").

• Why event-driven systems need it:

  • Brokers redeliver on failure, timeouts, or rebalances, so a consumer sees the same message twice.

  • Without idempotency, duplicates cause double charges, duplicate orders, or corrupted counters.

• How to achieve it:

  • Attach a unique idempotency key / event ID and record processed IDs; skip if already seen (dedup table).

  • Prefer naturally idempotent operations (upserts, absolute state) over relative deltas.

  • Use conditional writes / optimistic concurrency to reject stale replays.

Graceful degradation is designing a system so that when a dependency fails, it continues serving a reduced but useful experience instead of failing entirely. The core feature stays available while non-essential parts are dropped.

• The idea:

  • Partial functionality beats a full outage: fail soft, not hard.

  • Requires distinguishing critical paths from optional enrichments.

• Example:

  • An e-commerce product page: if the recommendations service is down, still render the product, price, and buy button, just hide the "You may also like" section.

  • Serve stale cached data when the source of truth is unavailable.

• How it's implemented:

  • Fallbacks (defaults, cached values, empty results) triggered by circuit breakers or timeouts.

  • Feature flags to disable heavy features under load.

Retry with exponential backoff means waiting progressively longer between attempts (e.g. 1s, 2s, 4s), and jitter adds randomness to those delays. Jitter is important because it spreads retries out in time, preventing many clients from retrying in synchronized waves that hammer a recovering service.

• Exponential backoff:

  • Delay grows as base * 2^attempt, usually capped by a max delay and a max attempt count.

  • Gives the downstream time to recover instead of retrying instantly.

• Jitter:

  • Randomizes each delay so clients don't align on the same retry instant (the "thundering herd").

  • "Full jitter" picks a random value between 0 and the computed backoff.

• Practical guards: Only retry transient/idempotent operations; cap total attempts to avoid retry storms.

Rate limiting caps how many requests a client may make in a time window; throttling is the enforcement action (delaying, queuing, or rejecting excess). Together they protect services from overload, abuse, and cascading failure while ensuring fair resource sharing.

• Rate limiting = the policy: e.g. 100 requests/minute per API key or IP; exceeding it typically returns 429 Too Many Requests.

• Throttling = the enforcement: Reject, delay, or smooth traffic once the limit is hit.

• Common algorithms:

  1. Token bucket: allows bursts up to bucket size, refills at a steady rate.

  2. Leaky bucket: enforces a smooth constant output rate.

  3. Fixed/sliding window: counts requests per time interval.

• Why it matters:

  • Prevents resource exhaustion and DoS from a single noisy client.

  • Ensures fairness (no tenant starves others) and protects downstream services from overload.

  • Usually enforced at the API gateway so backends stay simple.

Timeouts bound how long a caller waits before giving up. Without them a slow service ties up threads and connections in every upstream caller, and that resource exhaustion cascades until the whole chain collapses. Defaults are often extremely long or infinite, so relying on them is dangerous.

• Why timeouts are critical:

  • A slow response holds the caller's thread/connection; under load these pile up and exhaust the pool.

  • Exhaustion propagates upward: caller-of-caller also blocks, producing a cascading failure.

• Relying on defaults:

  • Many HTTP clients default to very long or no timeout, so a hung dependency hangs you too.

  • Users have already abandoned the request long before a 60s+ default fires.

• Good practice:

  • Set explicit, tuned timeouts (based on the dependency's latency percentiles) and separate connect vs read timeouts.

  • Pair timeouts with retries, circuit breakers, and a per-request deadline/budget so nested calls don't exceed the total.

Polyglot persistence means each microservice chooses the database technology best suited to its data and access patterns, rather than forcing one shared database on the whole system. A service might use a relational DB while another uses a document store, key-value cache, or graph DB.

• The idea: Right tool per job: relational for transactions, document for flexible schemas, key-value for caching, graph for relationships, search engines for full-text.

• Advantages:

  • Each service optimizes for performance and its natural data model.

  • Independent scaling and technology evolution per service.

  • Reinforces loose coupling (no shared schema).

• Disadvantages:

  • Operational overhead: more technologies to run, monitor, back up, and patch.

  • Broader skill set required across the team.

  • Cross-database transactions and joins become impossible; you need sagas and eventual consistency.

I'd frame it in business terms: the data will definitely become correct everywhere, just not at the exact same instant. There's a brief propagation lag between when a change is made and when every part of the system reflects it, in exchange for a system that stays fast and available.

• Use a familiar analogy: Like a bank transfer or a social media post: it shows up reliably, sometimes after a short delay, not always instantly on every screen.

• Explain the trade-off, not the tech:

  • Insisting on instant everywhere means slower responses and downtime if any part is unavailable.

  • Eventual consistency keeps the app fast and always-on; the lag is usually milliseconds to seconds.

• Reassure on correctness and scope:

  • No data is lost, and the system converges to one correct answer.

  • Where instant accuracy is legally required (e.g. a payment balance), we keep that strongly consistent; we relax it only where a short lag is harmless.

Eventual consistency is a consistency model where, after an update, replicas or services will converge to the same value given enough time and no new writes, but may serve stale data in the interim. It trades immediate correctness for availability and performance, and is the natural model for distributed systems where services own separate data stores.

• Core idea:

  • Writes propagate asynchronously (via events, replication, or async messaging), so reads may temporarily return old state.

  • Given a pause in updates, all copies eventually agree: convergence is guaranteed, timing is not.

• Why microservices lean on it:

  • Per the CAP theorem, favoring availability and partition tolerance means giving up strong consistency across services.

  • Sagas and event-driven flows update multiple services over time rather than in one atomic transaction.

• Where it is unacceptable (needs strong consistency):

  • Financial ledgers and account balances: you cannot let two withdrawals both see the old balance.

  • Inventory for scarce, high-value items where overselling causes real loss.

  • Authentication/authorization state: a revoked credential must not still grant access.

  • Regulatory/compliance records where a stale read has legal consequences.

• Mitigations when you must use it: Design UIs/APIs to tolerate staleness ("pending" states), use idempotent handlers, and set expectations on convergence windows.

A compensating transaction is a business-level action that semantically undoes the effect of a previously committed operation, used when you can't hold a lock across services. It differs from a database rollback in that nothing is truly reverted: you issue a new, forward-moving operation that offsets the old one.

• DB rollback is atomic and automatic: The transaction never committed, so no other reader ever saw the changes; the engine discards them.

• Compensation runs after commit:

  • The original change was already visible and possibly acted upon, so you apply an inverse business action (refund a charge, cancel a reservation).

  • It is not a perfect reversal: a refund is a new record, not the deletion of the charge.

• Used in Sagas: A multi-service workflow executes step by step; if a later step fails, earlier steps run their compensations in reverse order.

• Design implications:

  • Compensations must be idempotent and should handle the fact that intermediate states were externally visible.

  • Some actions can't be fully compensated (an email already sent); design so those come last.

2PC is avoided in microservices because it requires synchronous, blocking coordination and locks held across independent services, which destroys the availability and autonomy that microservices exist to provide. It couples services tightly to a single coordinator and scales poorly under failure.

• Blocking and locking: Participants hold resource locks from the prepare phase until commit, reducing throughput and increasing contention.

• Coordinator is a single point of failure: If the coordinator crashes after prepare but before commit, participants are stuck in-doubt, sometimes holding locks indefinitely.

• Reduced availability: By CAP, the synchronous all-or-nothing commit favors consistency at the cost of availability; one slow service stalls the whole transaction.

• Tight coupling: All participants must be up simultaneously and support the same distributed transaction protocol, breaking independent deployability.

• Doesn't fit heterogeneous stores: Many databases, queues, and third-party APIs don't support XA/2PC at all.

• The alternative: Sagas with local transactions, async events, and compensating actions accept eventual consistency in exchange for availability and loose coupling.

A liveness check answers "is this process alive or wedged?" while a readiness check answers "can this instance serve traffic right now?" They trigger different actions, so an orchestrator needs both to avoid killing healthy-but-busy pods and to avoid routing to broken ones.

• Liveness:

  • Detects a deadlocked or unrecoverable process; failure causes the orchestrator to restart the container.

  • Should be cheap and NOT depend on downstream services, or a failing dependency causes needless restart loops.

• Readiness:

  • Failure removes the instance from the load balancer / service endpoints, but does not restart it.

  • May check dependencies (DB, cache) or warm-up state, so an instance stops receiving traffic while still recovering.

• Why both:

  • Restart vs. de-register are distinct remedies: a temporarily-busy pod should be pulled from routing, not killed.

  • During startup, readiness prevents traffic before warm-up completes while liveness avoids premature kills (often paired with a startup probe).

The three pillars are metrics (aggregated numeric measurements over time), logs (discrete timestamped event records), and traces (the path of a single request across services). Together they let you detect a problem, understand it, and pinpoint where it happened, which is essential when a request fans out across many microservices.

• Metrics:

  • Cheap, aggregatable numbers (request rate, error rate, latency, CPU) ideal for dashboards and alerting.

  • Tell you THAT something is wrong, not why.

• Logs:

  • Rich per-event detail for debugging; best when structured (JSON) and carrying a correlation/trace ID.

  • Tell you WHAT happened inside one service.

• Traces:

  • A trace groups spans (one per service hop) sharing a trace ID to show the full request path and per-hop latency.

  • Tell you WHERE in the call chain the time or failure occurred.

• In microservices they are complementary: alert on metrics, jump to the trace to locate the slow service, read that service's logs for root cause.

Log aggregation collects and centralizes discrete log events from all services so you can search them in one place; distributed tracing reconstructs the end-to-end journey of a single request across services with timing. Aggregation tells you what each service logged; tracing tells you how one request flowed and where it spent time.

• Log aggregation:

  • Unit of data: an individual log line/event.

  • Answers "what error/message occurred?" across many sources.

  • Tools: ELK/EFK, Loki, Splunk.

• Distributed tracing:

  • Unit of data: a trace made of spans linked by a shared trace ID.

  • Answers "which hop was slow / where did the request fail?" with latency per service.

  • Tools: Jaeger, Zipkin, standardized by OpenTelemetry.

• They complement each other: attach the trace ID to log lines so you can pivot from a trace directly to the relevant logs.

Logs describe isolated events inside one service, but in a distributed system you also need to know the aggregate trend (are things degrading?) and the request's path across services (where is it degrading?). Metrics provide the aggregate signal for detection and alerting, and distributed tracing provides the cross-service context, which logs alone cannot give.

• Why logs alone fall short:

  • Per-event and per-service: no built-in aggregate view of rates or latency percentiles.

  • Hard to see cross-service causality without correlation and timing.

  • High volume makes them expensive to query for real-time alerting.

• Role of metrics:

  • Cheap time-series for dashboards, SLOs, and threshold/anomaly alerts (error rate, p99 latency).

  • First line of detection: tells you something is wrong quickly.

• Role of distributed tracing:

  • Pinpoints which service/hop caused latency or errors in a specific slow request.

  • Reveals dependency chains and fan-out you can't infer from a single log.

• Together: metrics alert, traces localize, logs explain the root cause.

Monitor the "RED" request-facing signals (Rate, Errors, Duration) per service, the "USE" resource signals (Utilization, Saturation, Errors) for infrastructure, plus business and dependency metrics. Together they cover both user-perceived health and underlying capacity.

• RED (per service/endpoint, user-facing health):

  • Rate: requests per second.

  • Errors: error rate / 5xx percentage.

  • Duration: latency percentiles (p50/p95/p99), not just averages.

• USE (resources):

  • Utilization: CPU, memory, disk, network.

  • Saturation: queue depth, thread-pool/connection-pool usage.

  • Errors: dropped packets, OOM kills, restarts.

• Dependency and integration metrics:

  • Downstream call latency/error rate, DB connection pool, cache hit ratio, message queue lag.

  • Circuit breaker state and retry counts.

• Business/SLO metrics: Domain outcomes (orders/sec, payment success rate) and error budget burn against SLOs.

Typically authentication happens once at the edge (API gateway), which validates the caller and issues or forwards a signed token; each downstream service then performs its own authorization based on the claims in that token. The JWT is propagated on every internal call (usually via the Authorization: Bearer header) so services can trust identity without re-authenticating against the identity provider.

• Authentication at the edge:

  • The gateway validates credentials (or an incoming token via OAuth2/OIDC) and rejects unauthenticated requests early.

  • Centralizes login concerns so individual services don't each handle credentials.

• Authorization per service:

  • Each service checks scopes/roles/claims in the JWT for its own resources (least privilege, defense in depth).

  • Don't trust the gateway alone: internal calls should still be verified (zero-trust).

• How the JWT is propagated:

  • Forwarded in the Authorization: Bearer <token> header on each downstream request.

  • Services validate the signature using the issuer's public key (JWKS) locally, so no per-request call to the auth server is needed.

  • Claims carry identity and permissions; a correlation/trace ID travels alongside for observability.

• Design considerations:

  • Keep tokens short-lived and use refresh tokens; consider token exchange for narrowed scopes between services.

  • A service mesh can add mTLS for service-to-service identity in addition to the JWT for user identity.

mTLS (Mutual TLS) is TLS where both the client and server present and verify X.509 certificates, so each side cryptographically proves its identity to the other. It gives service-to-service traffic encryption plus strong mutual authentication.

• Regular TLS authenticates only the server:

  • The client verifies the server, but the server has no proof of who the caller is.

  • mTLS adds a client certificate, so both endpoints are authenticated.

• Why it fits service-to-service:

  • Encrypts internal traffic (defense against network sniffing / east-west attacks).

  • Establishes a strong service identity instead of trusting IPs or network location.

  • Enables policy: only services with a valid cert issued by your CA can talk to a given service.

• Operational reality:

  • Requires a certificate authority and automated issuance/rotation of short-lived certs.

  • A service mesh (Istio, Linkerd) commonly automates mTLS via sidecars so app code stays unchanged.

The strangler fig pattern is an incremental migration strategy: you place a routing layer in front of the monolith and gradually redirect individual capabilities to new microservices, until the monolith is "strangled" and can be retired. It avoids a risky big-bang rewrite.

• The name / analogy: A strangler fig grows around a tree until the original is gone, mirroring the new system enveloping the old.

• How it works:

  1. Put a facade/proxy (often the API gateway) in front of the monolith.

  2. Pick one capability, build it as a new service, and route just those requests to it.

  3. Repeat capability by capability, keeping everything else on the monolith.

  4. Once nothing routes to the monolith, decommission it.

• Why it is preferred:

  • Low risk: small increments, each independently testable and reversible.

  • Delivers value continuously instead of a multi-year rewrite with no releases.

  • Old and new run side by side, so rollback is easy if a slice fails.

• Watch out: Data migration and keeping the two systems consistent during the transition is the hard part.

A shared database, where multiple services read and write the same tables, is an anti-pattern because it couples services at the data layer: it destroys their independence and turns a distributed system back into a monolith with hidden dependencies. The rule is database-per-service, each owning its schema.

• Why it breaks microservices:

  • Loss of encapsulation: services depend on each other's internal table structure, not a stable API.

  • Loss of independent deployability: a schema change can break several services at once.

  • Unclear ownership: no single team owns the data or its invariants.

• Risks of ignoring the rule:

  • Any migration requires coordinated, lockstep releases (a distributed monolith).

  • Contention and locking: one service's heavy query degrades others.

  • Bypassed business rules: another service can write invalid data directly, corrupting invariants.

  • Can't choose the right datastore per service or scale independently.

• The alternative:

  • Each service owns its data; others access it only via its API or via events.

  • Cross-service consistency handled with sagas / eventual consistency, not shared tables.

Both are release strategies that reduce risk, but Blue-Green switches all traffic between two full environments at once, while Canary shifts a small percentage of traffic to the new version gradually.

• Blue-Green deployment:

  • Two identical environments: Blue (current) and Green (new). You deploy to Green, test it, then flip the router to send 100% of traffic to Green.

  • Rollback is instant: switch traffic back to Blue.

  • Cost: you run double the infrastructure during the cutover.

• Canary deployment:

  • Route a small slice (e.g. 5%) of live traffic to the new version, watch metrics/errors, then progressively increase to 100%.

  • Catches problems with real production traffic while limiting blast radius.

  • Needs solid observability and traffic-splitting (service mesh, ingress, or load balancer).

• Key difference: Blue-Green is an all-at-once switch (fast rollback, higher cost); Canary is a gradual, metric-driven exposure (smaller blast radius, slower rollout).

Independently deployable means you can build, release, and deploy one service to production on its own schedule without coordinating a lockstep release of other services. It is the property that makes microservices worth their overhead.

• What it requires:

  • Loose coupling: services communicate over stable, versioned contracts (APIs, events), not shared internals.

  • No shared database schema that other services read/write directly.

  • Backward-compatible changes so consumers don't break when a producer deploys.

• If violated, you get a distributed monolith:

  • Services must be released together in a fixed order, reintroducing coordination overhead.

  • You pay the cost of distribution (network, latency, partial failure) without the benefit of independence.

  • A change in one service forces ripple redeploys, slowing every team.

Externalize config out of the artifact and load it at runtime, typically through a mix of environment variables, a central config service, and secret stores. The core trade-off is consistency and single-source control (centralized) versus autonomy and blast-radius isolation (per-service).

• How to manage it:

  • Inject non-secret config via environment variables or ConfigMaps.

  • Keep secrets in a dedicated store (Vault, cloud secret manager), never in the repo.

  • Use a central config server (Spring Cloud Config, Consul) or GitOps repo for shared/dynamic values, ideally with versioning and audit.

• Centralized config:

  • Pros: one source of truth, consistent values, easy global changes and auditing.

  • Cons: a shared dependency and potential single point of failure; a bad change can break many services; couples teams.

• Per-service config:

  • Pros: full team autonomy, isolated blast radius, no runtime dependency on a config server.

  • Cons: duplication and drift; harder to enforce standards or rotate shared secrets across many services.

• Common pattern: Centralize shared/cross-cutting values and secrets; keep service-specific tuning local, with sensible defaults baked in.

Feature flags decouple deployment from release: code ships to production dormant, and you turn the feature on later via configuration, without a redeploy. This lets you deploy continuously while controlling who sees what.

• Decouple deploy from release: Merge and deploy incomplete or risky code behind a flag that stays off until it's ready.

• Progressive rollout and targeting: Enable for internal users, a percentage of traffic, or specific segments, effectively an application-level canary.

• Instant kill switch: If a feature misbehaves, toggle it off in seconds instead of rolling back a deploy.

• Enables trunk-based development: Teams integrate to main frequently instead of maintaining long-lived branches.

• Costs to manage:

  • Flags add code paths and testing combinations; treat them as technical debt and remove stale ones.

  • Long-lived flags need governance so state stays consistent across service instances.

The 'operational tax' is the ongoing cost of running many independent, network-connected services: infrastructure, monitoring, and coordination that a monolith simply doesn't incur. It shows up sharply in testing, deployment, and debugging.

• Testing:

  • Integration and end-to-end tests span multiple services and networks, so they're slower and flakier.

  • You need contract testing (e.g. Pact) to catch breaking API changes without spinning up everything.

• Deployment:

  • Many independent pipelines, versioned APIs, and backward compatibility during rolling releases.

  • Requires orchestration (Kubernetes), service discovery, and config management.

• Debugging:

  • A single request crosses many services, so you need distributed tracing (OpenTelemetry, correlation IDs) and centralized logging.

  • Failures are partial and intermittent: network timeouts, cascading failures, eventual-consistency bugs.

• Net effect: You trade code complexity for operational and infrastructure complexity; the tax is only worth paying at sufficient scale and team size.

The fallacies of distributed computing are eight false assumptions (originally by Peter Deutsch and others) that developers make about networks. Microservices are distributed systems, so ignoring these fallacies leads directly to fragile, slow, and unreliable systems.

• The network is reliable: Calls fail; use retries, timeouts, and circuit breakers instead of assuming success.

• Latency is zero: Every remote call costs time; chatty inter-service calls kill performance, so design coarser APIs.

• Bandwidth is infinite: Large payloads add up; be mindful of message sizes and volume.

• The network is secure: Assume it isn't: use TLS, authentication, and authorization between services.

• Topology doesn't change: Instances come and go; rely on service discovery, not hardcoded addresses.

• There is one administrator: Many teams and dependencies; coordinate versioning and ownership explicitly.

• Transport cost is zero: Serialization and infrastructure have real cost; account for it.

• The network is homogeneous: Services differ in protocols and formats; standardize on interoperable contracts.

The right size is driven by business capability and cohesion, not lines of code: a service should own one clear responsibility, be independently deployable, and be maintainable by a single team. 'Small enough to rewrite, large enough to be meaningful' is the guiding intuition, not an arbitrary size limit.

• Sizing heuristics:

  • Align with a bounded context / business capability so the service has a single reason to change.

  • Fits the cognitive load of one team ('two-pizza team'), and can be deployed and reasoned about independently.

• Dangers of nanoservices (too small):

  • Chatty communication: logic that would be an in-process call becomes many network hops, adding latency and failure points.

  • Distributed transactions and consistency headaches when one operation spans too many tiny services.

  • Operational overhead: more repos, pipelines, dashboards, and deployments than the value justifies.

  • Hidden coupling: fragments that always change together should have been one service.

• Practical advice: Start coarser and split when you see real pressure (independent scaling, differing change rates, team boundaries) rather than pre-fragmenting.

You draw boundaries where the business does: around cohesive capabilities that change together and can be owned end-to-end by one team, minimizing cross-service chatter. The two common approaches, business capability and sub-domain (DDD), are complementary lenses that often converge on similar boundaries.

• Principles for drawing boundaries:

  • Maximize cohesion inside, minimize coupling across: things that change together belong together.

  • Follow data ownership: a service should own its data and not share a database with others.

  • Watch communication patterns: overly chatty boundaries signal a bad split.

• Decompose by business capability: Organize around what the business does (e.g. Ordering, Billing, Shipping), derived from the org's value streams.

• Decompose by sub-domain (DDD): Analyze the problem space into core, supporting, and generic sub-domains, then map each to a bounded context and service.

• The difference: Capability decomposition starts from the business's structure/functions; sub-domain decomposition starts from the domain model and its language. They frequently align, and using both cross-checks your boundaries.

High cohesion means a service's internal parts are strongly related and serve one purpose; loose coupling means services depend on each other minimally and only through stable contracts. They go together: putting related behavior in one service (cohesion) naturally reduces the cross-service dependencies (coupling) needed to get work done.

• High cohesion:

  • All the logic for one capability lives in one service, so a change to that capability is contained in one place.

  • Poor cohesion forces a single feature change to span many services.

• Loose coupling:

  • Services interact via well-defined APIs or events and hide internals; you can change or deploy one without redeploying others.

  • Sharing databases or internal models creates tight coupling and defeats independence.

• The relationship: Low cohesion tends to produce high coupling: scattered responsibilities require constant cross-service calls. Getting boundaries right (bounded contexts) improves both at once.

• How to measure:

  • Change coupling: how often do commits/deploys span multiple services together? Frequent co-changes signal bad boundaries.

  • Afferent/efferent coupling: count of services that depend on it vs. it depends on.

  • Call fan-out: number of synchronous downstream calls per request indicates chattiness.

  • Cohesion smell: does the service have one clear responsibility, or unrelated endpoints bundled together?

Both aim to draw service boundaries around cohesive concerns, but they come from different viewpoints: business capability decomposition is organizational (what the business does), while sub-domain decomposition is DDD-driven (how the problem domain naturally partitions).

• Decompose by business capability:

  • Based on what the organization does to generate value (e.g. Order Management, Inventory, Shipping, Billing).

  • Stable over time because capabilities change slowly even as implementation changes.

  • Often mirrors the org chart, which aligns with Conway's Law.

• Decompose by sub-domain (DDD):

  • Analyzes the problem domain and splits it into core, supporting, and generic sub-domains.

  • Each sub-domain maps to a bounded context with its own ubiquitous language and model.

  • Focuses effort: invest heavily in core sub-domains, buy or outsource generic ones.

• Relationship:

  • They usually converge: a well-identified capability and sub-domain often describe the same boundary from different angles.

  • Capability thinking answers "what services do we need"; sub-domain thinking answers "where are the model boundaries".

Share genuinely stable, non-business logic (utilities, clients, contracts) as versioned artifacts, but keep domain logic inside each service: shared business rules recreate the tight coupling microservices exist to avoid.

• What is safe to share:

  • Cross-cutting technical concerns: logging, tracing, auth helpers, serialization.

  • Contracts/schemas (e.g. Protobuf, OpenAPI, event schemas) so producers and consumers agree.

  • Thin generated clients for calling another service.

• What to avoid sharing:

  • Domain/business logic: it forces lockstep deploys and leaks one context's model into another.

  • Shared database entities/ORM models spanning services.

• How to share without coupling:

  • Publish as independently versioned libraries with semantic versioning; consumers upgrade on their own schedule.

  • Keep libraries small and single-purpose so a change rarely touches everyone.

  • Prefer duplication over a leaky abstraction when logic is likely to diverge per service.

An Anti-Corruption Layer (ACL) is a translation layer that sits between your bounded context and an external or legacy system, converting their model into yours so foreign concepts don't leak in and corrupt your domain model.

• Purpose:

  • Protects the integrity of your ubiquitous language and model from an upstream model you don't control.

  • Isolates the mess: adapters, translators, and facades map their terms/data structures to yours in one place.

• When to use one:

  • Integrating with a legacy system or third-party API whose model conflicts with yours.

  • Consuming another team's service whose contract is unstable or poorly aligned with your domain.

  • During a strangler-fig migration, to shield the new service from the old system.

• Trade-off: Adds code and a translation cost, but contains change: when the external model shifts, only the ACL updates.

Orchestration uses a central coordinator that tells each service what to do and in what order; choreography has no central brain: services react to events and decide their own next step. Choreography generally scales better because it removes the central bottleneck and coupling, though it's harder to observe and reason about.

• Orchestration (command-driven):

  • A central orchestrator invokes services and manages the workflow state (e.g. a Saga orchestrator).

  • Pros: explicit, easy to visualize, monitor, and change the flow in one place; simpler error handling/compensation.

  • Cons: the orchestrator is a coupling point and potential bottleneck/single point of failure; services depend on it.

• Choreography (event-driven):

  • Each service publishes events and subscribes to others' events, reacting independently.

  • Pros: loose coupling, no central bottleneck, easy to add new consumers, scales horizontally.

  • Cons: no single view of the workflow, harder to debug/trace, risk of cyclic or emergent behavior.

• Which is more scalable and why:

  • Choreography scales better: it avoids a central coordinator, so services fail and evolve independently and load spreads across the broker.

  • Trade-off: you buy scalability with reduced visibility, so many teams use orchestration for complex, tightly-governed flows and choreography for high-volume, loosely-coupled ones.

A Service Mesh is a dedicated infrastructure layer that manages service-to-service (east-west) communication, implemented by injecting a sidecar proxy next to every service so networking concerns are handled outside application code. An API Gateway, by contrast, manages north-south traffic (external clients into the system); they solve different problems and often coexist.

• Anatomy of a mesh:

  • Data plane: sidecar proxies (e.g. Envoy) intercept all inbound/outbound traffic for their service.

  • Control plane: configures the proxies (e.g. Istio, Linkerd) with routing, policy, and certs.

• What it provides: mTLS encryption, retries/timeouts, circuit breaking, traffic splitting (canary), and uniform telemetry, all without app code changes.

• vs. API Gateway:

  • Direction: gateway handles external-to-internal (north-south); mesh handles internal service-to-service (east-west).

  • Scope: gateway is a centralized edge component; the mesh is distributed across every service via sidecars.

  • Concerns: gateway focuses on client-facing API management (auth, rate limits); mesh focuses on internal reliability, security, and observability.

The Bulkhead pattern isolates resources into separate pools so a failure or overload in one part can't consume everything and sink the whole system. It's named after ship compartments: a breach floods one section, not the entire hull.

• The problem it solves: If all calls share one thread pool or connection pool, one slow dependency can exhaust it and block requests to healthy dependencies too.

• How it works:

  • Partition resources: give each dependency (or client tier) its own thread pool, connection pool, or instance set.

  • When one pool saturates, only calls to that dependency fail/queue; the rest keep working.

• Benefits:

  • Contains failures and prevents cascading resource exhaustion.

  • Can prioritize critical traffic by giving it a dedicated bulkhead.

• Often combined with: Circuit breakers and timeouts for layered resilience.

A cascading failure is when the failure of one service triggers failures in its callers, spreading through the dependency graph until large parts of the system collapse. It typically happens when a slow or failing service ties up resources (threads, connections) in every service that calls it.

• How it spreads:

  • Service B slows down, so callers of B block waiting; their thread/connection pools exhaust, so their callers fail too.

  • Retries amplify load on the already-struggling service, accelerating collapse.

• Prevention techniques:

  • Timeouts: never wait indefinitely on a downstream call.

  • Circuit breakers: stop calling a failing service and fail fast.

  • Bulkheads: isolate resources per dependency so one saturation doesn't sink everything.

  • Rate limiting and load shedding: reject excess work rather than queueing it forever.

  • Bounded retries with backoff and jitter to avoid amplification.

  • Graceful degradation and fallbacks to contain the blast radius.

Backpressure is a mechanism by which a consumer signals it can't keep up, forcing producers to slow down instead of overwhelming the system. It protects a slow consumer from being buried by a fast producer, preventing memory exhaustion and unbounded queue growth.

• Why it matters:

  • Without it, an overwhelmed consumer accumulates an ever-growing backlog, leading to OOM crashes, rising latency, and cascading failure.

  • It keeps the system stable under load rather than letting it fail catastrophically.

• How it's applied:

  • Pull-based consumption: consumers fetch at their own pace (e.g. Kafka consumers polling), so the broker acts as a buffer.

  • Bounded queues / prefetch limits (prefetch in RabbitMQ) so a consumer only holds what it can process.

  • Flow control in reactive streams (request(n)) where the consumer requests demand.

  • Load shedding: drop or reject when saturated rather than accept everything.

A retry storm happens when many clients retry a struggling service simultaneously, multiplying its load exactly when it can least handle it and pushing it fully over. You prevent it by making retries polite (bounded, spaced, and adaptive) and by letting the service protect itself.

• Tame the retries:

  • Exponential backoff with jitter so retries don't align.

  • Cap the number of retries; never retry indefinitely.

  • Don't retry at every layer: retrying in service A, B, and C multiplies attempts. Retry at one level.

• Stop early when it's clearly down:

  • Circuit breaker: once failures cross a threshold, fail fast and stop sending traffic to give it room to recover.

  • Retry budgets: allow retries only up to a small percentage of total requests (e.g. 10%).

• Let the server push back: Honor Retry-After headers and use load shedding / rate limiting to reject excess quickly.

Retry with backoff is a recovery pattern that reattempts a failed call, assuming the failure is transient. Bulkhead is an isolation pattern that partitions resources so a failure in one dependency can't consume the resources needed by others. They solve different problems and are usually used together.

• Retry with backoff:

  • Goal: recover from transient failures (blips, momentary timeouts).

  • Use when the operation is idempotent and the error is likely temporary.

  • Risk if misused: amplifies load on a truly-down service.

• Bulkhead:

  • Goal: contain failure by isolating resources (e.g. separate thread/connection pools per downstream).

  • Use when one slow dependency could exhaust shared resources and take down unrelated features.

  • Named after ship compartments: one flooded section doesn't sink the ship.

• When to choose: Retry addresses "the call might succeed if I try again"; bulkhead addresses "this call must not starve everything else." Combine them with timeouts and circuit breakers for real resilience.

You isolate the failure so it can't cascade: combine timeouts, circuit breakers, bulkheads, and fallbacks so a slow dependency degrades one feature instead of exhausting shared resources across the whole system.

• Aggressive timeouts: Never wait indefinitely: fail fast so callers release threads/connections instead of piling up.

• Circuit breakers: After repeated failures the breaker opens and short-circuits calls, giving the downstream time to recover instead of hammering it.

• Bulkheads: Isolate resources (separate thread/connection pools per dependency) so one saturated dependency can't consume every thread.

• Fallbacks and graceful degradation: Return a cached value, default, or partial response when the dependency is down.

• Retries with backoff (carefully): Add jitter and cap attempts; blind retries against a slow service make the overload worse.

• Load shedding and async decoupling: Drop or queue excess work; use a message broker to remove synchronous coupling where possible.