Top 50 Microservices Architecture Interview Questions & Answers (2026)

Microservices is an architectural style where an application is structured as a collection of small, independently deployable services, each running in its own process and communicating over lightweight mechanisms such as HTTP/REST or message queues. Each service is built around a specific business capability — for example, a user service, an order service, and a payment service — and can be developed, deployed, and scaled independently. This contrasts sharply with a monolith where all functionality lives in a single deployable unit. Teams at companies like Netflix and Amazon popularized microservices to allow hundreds of small teams to ship software independently without coordinating deployments.

A monolith packages all application functionality — UI, business logic, data access — into a single deployable unit. Any change requires redeploying the entire application, and the codebase can become difficult to understand and scale over time. Microservices decompose the application into independently deployable services. The tradeoffs are significant: monoliths are simpler to develop and debug initially but become hard to scale and change; microservices offer independent scaling and deployment but introduce distributed systems complexity such as network latency, partial failure, and data consistency challenges. Neither is universally better — the right choice depends on team size, organizational maturity, and domain complexity.

A bounded context is a central concept in Domain-Driven Design (DDD) that defines the explicit boundary within which a particular domain model applies. Inside a bounded context, all terms, rules, and models have a precise, unambiguous meaning. For example, the word "Customer" might mean different things in a billing context (a payer with a credit card) versus a shipping context (a recipient with an address). Microservices naturally align with bounded contexts — each service owns its model, its database, and its language, preventing the muddy, inconsistent models that plague large shared databases. Bounded contexts are identified through a practice called Event Storming.

Service discovery is the mechanism by which services in a microservices system find each other's network locations (IP address and port) without hard-coding them — especially important because services can scale up, move, or fail at any time. There are two patterns: Client-side discovery (e.g., Netflix Eureka) where the calling service queries a service registry itself and performs load balancing; and Server-side discovery (e.g., AWS ALB, Kubernetes Service) where the caller sends requests to a load balancer or proxy that looks up the registry and forwards the request. Service registries like Consul, Eureka, and etcd store the current network location of each service instance.

An API gateway is a server that acts as the single entry point for all client requests to a microservices system. Instead of clients calling dozens of backend services directly, they call the gateway, which routes requests to the appropriate service, aggregates responses, handles authentication and authorization, enforces rate limiting, and provides SSL termination. Popular API gateways include Kong, AWS API Gateway, NGINX, and Netflix Zuul. The API gateway pattern reduces client complexity, centralizes cross-cutting concerns, and shields internal service topology from external clients. The tradeoff is that it can become a bottleneck and a single point of failure if not deployed carefully.

Load balancing distributes incoming requests across multiple instances of a service to prevent any single instance from becoming overwhelmed, improving availability and throughput. In microservices, load balancing can happen at multiple levels. Client-side load balancing (e.g., Netflix Ribbon, gRPC built-in) means the calling service picks an instance from the registry using an algorithm like round-robin or least-connections. Server-side load balancing uses a dedicated proxy (NGINX, HAProxy, Kubernetes Service) in front of the service instances. Kubernetes handles load balancing automatically through its Service abstraction, distributing traffic across all healthy pods in a Deployment.

In synchronous communication, the calling service sends a request and waits (blocks) for a response before continuing — like an HTTP/REST call or gRPC call. This is simple to reason about but creates temporal coupling: if the downstream service is slow or unavailable, the caller is blocked too, and failures can cascade. In asynchronous communication, the caller sends a message (event) to a broker (Kafka, RabbitMQ) and continues immediately without waiting for a response. The receiver processes the message in its own time. Async communication decouples services in time, improves resilience to downstream failures, and naturally supports event-driven architectures, but it makes tracking the overall flow of a business operation more complex.

REST (Representational State Transfer) uses HTTP with JSON or XML payloads. It is human-readable, easy to debug with standard tools like curl and browsers, and widely understood. However, JSON parsing is relatively slow and verbose. gRPC is Google's high-performance Remote Procedure Call framework that uses Protocol Buffers (binary serialization) over HTTP/2. gRPC is significantly faster and more bandwidth-efficient than REST, supports strongly-typed contracts via .proto files, and enables bidirectional streaming. gRPC is ideal for internal service-to-service communication where performance matters, while REST is preferred for public-facing APIs where broad client compatibility is needed.

The database per service pattern is a core microservices principle stating that each service should own and manage its own database, and no other service should access that database directly. This ensures loose coupling — a service can change its database schema without breaking other services. Services expose their data only through their API. In practice, this means you might have PostgreSQL for the order service, MongoDB for the catalog service, and Redis for the session service — this mix is called polyglot persistence. The challenge is managing data consistency across service boundaries, which requires patterns like Sagas and event-driven synchronization rather than distributed transactions.

Docker containers are the natural packaging format for microservices. A container bundles a service's code, runtime, libraries, and configuration into a single, portable image that runs identically in development, testing, and production. Each microservice becomes its own Docker image, and multiple services can run on the same host without interfering with each other's dependencies. Docker eliminates the "it works on my machine" problem by encapsulating all dependencies. When combined with an orchestrator like Kubernetes, containers can be automatically scheduled, scaled, restarted on failure, and updated with zero-downtime rolling deployments, making Docker's container model foundational to operating microservices at scale.

A service mesh is a dedicated infrastructure layer for handling service-to-service communication in a microservices system. It is implemented by deploying a lightweight proxy (sidecar) alongside each service instance. The sidecar intercepts all network traffic and provides features like mutual TLS (mTLS) for encrypted service-to-service communication, automatic retries, circuit breaking, distributed tracing, and traffic management — all without any changes to the service code itself. Popular service meshes include Istio and Linkerd. The tradeoff is operational complexity: running a service mesh adds infrastructure overhead and requires dedicated expertise to configure and maintain.

Fault tolerance in microservices means designing services to continue operating correctly even when some of their dependencies fail. Because microservices communicate over a network, partial failures are inevitable. Key fault tolerance techniques include: Timeouts (don't wait indefinitely for a response), Retries with exponential backoff (retry transient failures but avoid overwhelming a recovering service), Circuit Breakers (stop calling a failing service entirely for a period), and Fallbacks (return cached data or a degraded response when the primary path fails). Without fault tolerance, a single slow downstream service can exhaust all threads in the calling service and cause a cascading failure across the entire system.

Health checks are endpoints (typically /health) that a service exposes to indicate whether it is functioning correctly. In Kubernetes, there are two specific types: A liveness probe checks whether a service is alive — if it fails repeatedly, Kubernetes restarts the container. This handles hung or deadlocked processes. A readiness probe checks whether a service is ready to accept traffic — if it fails, Kubernetes removes the pod from the Service load balancer without restarting it. This prevents traffic from being routed to a service that is still warming up, connecting to its database, or temporarily overloaded. Both probes are essential for zero-downtime deployments and reliable operation.

A service registry is a database that stores the network locations (host, port, metadata) of all running service instances. Services register themselves when they start and deregister when they stop. Other services query the registry to discover where to send requests. It is the phone book of a microservices system. Popular service registries include: Consul (by HashiCorp, supports health checking, KV store, and DNS-based discovery), Eureka (by Netflix, Java-based, REST API), and etcd (distributed key-value store used by Kubernetes internally). In Kubernetes, the Service resource and CoreDNS provide built-in service discovery without needing a separate registry.

Inter-service communication refers to how microservices exchange data and coordinate with each other over a network. Unlike a monolith where modules call each other in-process (fast, reliable), inter-service calls cross network boundaries, introducing challenges: Latency (network calls are orders of magnitude slower than in-process calls), Partial failure (the downstream service might be unavailable), Data serialization overhead (converting objects to JSON or protobuf and back), and Version compatibility (services must handle different versions of each other's API). These challenges require deliberate design decisions around synchronous vs. asynchronous communication, retry strategies, timeouts, and API versioning.

An event bus is a shared communication channel through which microservices publish and subscribe to events. When a service completes an action — for example, an order is placed — it publishes an event to the bus. Any number of other services (email service, inventory service, analytics service) can subscribe to that event and react independently, without the publisher needing to know who is listening. This enables loose coupling: adding a new subscriber requires no changes to the publisher. Common event bus implementations include Apache Kafka (high-throughput, durable, ordered), RabbitMQ (flexible routing, broker-based), and cloud-native options like AWS SNS/SQS and Google Pub/Sub.

A stateless service does not store any client session data or in-memory state between requests. Every request contains all the information needed to process it, and any persistent data is stored in an external store (database, cache, object storage). Stateless services are strongly preferred in microservices because they are trivially horizontally scalable — you can add or remove instances freely because any instance can handle any request. Load balancers can route to any instance without sticky sessions. Deployments and restarts are seamless because there is no state to preserve or migrate. Authentication state, for example, is typically stored in a JWT token (sent with each request) rather than in server-side session memory.

Horizontal scaling (scaling out) means adding more instances of a service to handle increased load, rather than upgrading the hardware of a single instance (vertical scaling). Microservices are designed for horizontal scaling — because each service is stateless and independently deployable, you can scale only the services that are under load without touching others. For example, if the image-processing service is the bottleneck, you scale it from 2 to 20 instances while leaving the user service unchanged. Kubernetes Horizontal Pod Autoscaler (HPA) automates this by monitoring CPU/memory metrics and automatically adding or removing pods. This is one of the primary cost and performance advantages of microservices over monoliths.

Polyglot persistence is the practice of using different database technologies for different microservices, choosing the best tool for each service's specific data needs rather than forcing all services to use one shared database. For example: the product catalog service uses Elasticsearch for full-text search, the session service uses Redis for fast key-value lookups, the order service uses PostgreSQL for ACID-compliant relational data, and the activity feed service uses Cassandra for high-write time-series data. This approach maximizes efficiency but requires operational expertise across multiple database technologies and makes cross-service queries (which should be avoided anyway) impossible via SQL joins.

Event-driven architecture (EDA) is a design paradigm where services communicate by producing and consuming events — records of things that happened — rather than by calling each other directly. A service publishes an event (e.g., OrderPlaced) to a broker without knowing who will consume it. Interested services subscribe and react asynchronously. This creates extremely loose coupling and enables patterns like event sourcing and CQRS. In a microservices system, EDA allows a single business action to trigger work across many services (email, inventory, analytics) without any of them being tightly coupled. The main challenges are eventual consistency, lack of a single synchronous response, and making distributed workflows observable and debuggable.

The Saga pattern manages long-running distributed transactions across multiple microservices without using a two-phase commit. A saga is a sequence of local transactions, each updating one service's database and publishing an event or message to trigger the next step. If any step fails, the saga executes compensating transactions to undo the completed steps. There are two coordination styles: Choreography, where each service reacts to events and publishes new events with no central coordinator (simpler but harder to observe), and Orchestration, where a central saga orchestrator explicitly commands each participant and handles failure logic (more visible and easier to debug). Sagas are essential for order checkout flows, booking systems, and any multi-service business transaction.

CQRS separates the write model (Commands — which change state) from the read model (Queries — which return data). Instead of a single model serving both reads and writes, you have two: a command stack that processes state-changing operations and emits events, and one or more query stacks that maintain denormalized, read-optimized views of the data built from those events. This allows the read model to be independently scaled, independently structured (e.g., a materialized view in Redis or Elasticsearch optimized for specific queries), and independently deployed. CQRS is powerful but adds significant complexity — it is most beneficial in systems with high read/write asymmetry or where reads need very different data shapes than writes produce.

Event sourcing stores the state of an entity as an ordered sequence of events rather than as a current snapshot. Instead of a row in a database that gets overwritten with UPDATE, you append an event like OrderPlaced, OrderShipped, OrderCancelled to an append-only event log. The current state is derived by replaying all events. Benefits include a complete audit trail, the ability to replay events to rebuild state or create new projections, and natural integration with event-driven architectures. The challenges are that querying the current state requires projection maintenance, the event schema must be carefully versioned, and the event log can grow very large over time requiring snapshotting strategies.

The Circuit Breaker pattern prevents a service from repeatedly calling a downstream service that is failing, which would waste resources and potentially cascade the failure. It works like an electrical circuit breaker: in the Closed state, requests pass through normally; if failures exceed a threshold, it trips to the Open state, where all requests immediately fail with a fallback (no network call is made); after a timeout, it enters the Half-Open state where a single test request is sent — if it succeeds, the breaker closes again, otherwise it opens again. Libraries like Resilience4j (Java) and Polly (.NET) provide circuit breaker implementations. Service meshes like Istio can also enforce circuit breaking transparently without library changes.

The Bulkhead pattern isolates resources (thread pools, connection pools, semaphores) used for different downstream services so that a failure or slowdown in one does not exhaust resources for others. Named after ship bulkheads that partition the hull into watertight compartments so that flooding one section does not sink the ship. In practice, if Service A calls Service B and Service C, you assign separate thread pools to each — if Service B becomes slow and fills its thread pool, calls to Service C continue unaffected. Resilience4j and Hystrix implement bulkheads via thread pool isolation or semaphore isolation. Bulkheads are a key tool for preventing cascading failures in high-traffic microservices systems.

Distributed tracing tracks a single user request as it flows through multiple microservices, collecting timing and metadata at each hop to give a complete picture of the request's journey. When a request enters the system, a unique trace ID is generated and propagated in request headers through every service call. Each service creates spans — individual units of work with a start time, duration, and metadata — that are sent to a central tracing backend. Tools like Jaeger and Zipkin visualize the complete trace, showing the full call tree and where latency is being added. This is essential for debugging performance issues and understanding service dependencies in complex microservices topologies.

Kubernetes is the de facto orchestration platform for microservices. A Deployment manages a set of identical pod replicas (service instances), handling rolling updates and rollbacks. A Service provides a stable DNS name and virtual IP for a set of pods, enabling service discovery and load balancing. An Ingress resource routes external HTTP/S traffic to internal services, acting as an API gateway entry point. ConfigMaps and Secrets inject configuration and sensitive data. Horizontal Pod Autoscaler automatically scales pods based on metrics. Namespaces provide isolation between teams or environments. Kubernetes removes the need to manually manage service instances and provides a self-healing platform that restarts failed containers automatically.

Apache Kafka is a distributed log designed for high-throughput, durable, ordered event streaming. Messages are persisted to disk for a configurable retention period (days or weeks), consumers track their own offset, and messages can be replayed. Kafka excels at event sourcing, audit logs, stream processing (with Kafka Streams or Flink), and scenarios requiring very high throughput (millions of messages/sec). RabbitMQ is a traditional message broker designed for flexible message routing. Messages are pushed to consumers and acknowledged — once acknowledged, they are deleted. RabbitMQ supports complex routing topologies (exchanges, bindings), dead-letter queues, and is simpler to operate at smaller scale. Choose Kafka for event streaming and replay; choose RabbitMQ for task queues and flexible routing patterns.

The API composition pattern is used to query data that is spread across multiple microservices. An API composer (typically the API gateway or a dedicated aggregator service) makes parallel calls to multiple services and merges their results into a single response for the client. For example, displaying an order detail page might require fetching order data from the order service, customer info from the customer service, and shipping status from the shipping service — the composer retrieves all three and combines them. The limitation is that API composition only works well for simple aggregations; complex queries (like a filtered, sorted, paginated list spanning multiple services) require a separate CQRS read model or search index instead.

The Transactional Outbox pattern solves the dual-write problem: how to atomically update a database AND publish an event to a message broker. If you write to the database and then publish to Kafka, the two are not atomic — a crash between them leaves you with either missing events or orphaned events. The solution: write the event to an outbox table in the same local database transaction as the business data update. A separate Message Relay process (e.g., using Debezium CDC — Change Data Capture) reads from the outbox table and publishes the events to the broker. This guarantees exactly-once semantics at the database level, even if the service crashes, because the event is committed atomically with the business data.

Two-phase commit (2PC) is a distributed transaction protocol that coordinates multiple participants to either all commit or all rollback a transaction. It requires a coordinator that first sends a "prepare" request to all participants (phase 1) and then, if all agree, a "commit" (phase 2). In microservices, 2PC is problematic for several reasons: it creates tight coupling between services and the coordinator, it is blocking — participants hold locks during the protocol, reducing throughput significantly, the coordinator is a single point of failure, and it does not work across heterogeneous databases (SQL + NoSQL). The recommended alternative is the Saga pattern with compensating transactions, which achieves eventual consistency without distributed locking.

Istio is a powerful service mesh that provides cross-cutting communication features without any application code changes, through sidecar proxies (Envoy). Key features include: Mutual TLS (mTLS) — automatic encryption and certificate-based authentication for all service-to-service traffic; Traffic management — fine-grained routing rules for canary releases, A/B testing, and weighted traffic splitting; Observability — automatic metrics (Prometheus), distributed tracing (Jaeger/Zipkin), and access logs for every service call; Circuit breaking and retries — configured via Kubernetes custom resources; and Authorization policies — define which services are allowed to call which endpoints. The tradeoff is significant operational overhead — Istio adds latency and requires expertise to configure correctly.

Blue-green deployment maintains two identical production environments (blue and green). The new version is deployed to the inactive environment (e.g., green), fully tested there, and then the load balancer switches 100% of traffic to green instantly. If a problem occurs, rollback is instant — just switch back to blue. Canary release gradually shifts a percentage of traffic to the new version — for example, 1% → 5% → 25% → 100% — while monitoring error rates and latency. If metrics degrade, the canary is aborted and all traffic returns to the old version. Canary releases reduce blast radius: only a small percentage of users experience potential bugs before you commit to a full rollout. Both strategies enable zero-downtime deployments.

The sidecar pattern attaches a helper container to a main service container, running alongside it in the same pod (in Kubernetes) and sharing the same network namespace and lifecycle. The sidecar handles cross-cutting concerns that are not part of the core business logic — such as logging, monitoring, configuration management, service mesh proxy (Envoy in Istio), or TLS termination — so the main service can focus on its domain. For example, a log aggregation sidecar collects logs from the main container and ships them to Elasticsearch. This avoids duplicating infrastructure code in every service and enables you to add or upgrade capabilities without modifying service code, promoting the single responsibility principle at the infrastructure level.

Because each microservice has its own database, achieving data consistency across services is one of the hardest challenges in microservices. The primary approach is eventual consistency — accepting that data will be temporarily inconsistent between services but will converge to a consistent state given enough time. The main patterns are: Saga pattern for managing multi-step business transactions with compensating rollbacks; Event-driven synchronization where services publish domain events and others update their own local copies of the data; and Idempotency to safely handle duplicate message delivery. The key is to design business processes that tolerate temporary inconsistency — for example, showing "pending" status rather than requiring immediate strong consistency for every operation.

An operation is idempotent if performing it multiple times produces the same result as performing it once. In microservices, network failures and retries mean a message or request can be delivered more than once — idempotency ensures that duplicate deliveries do not cause duplicate side effects (e.g., charging a customer twice). Common techniques include: using a unique idempotency key (request ID) that the server stores after processing — if the same key arrives again, return the cached result without reprocessing; using database unique constraints to prevent duplicate inserts; or designing operations that are naturally idempotent (like "set status to SHIPPED" rather than "decrement inventory by 1"). Idempotency is essential for at-least-once messaging systems like Kafka and for retries in circuit breakers.

As services evolve, their APIs must be versioned to allow consumers to upgrade at their own pace without breaking changes. Common strategies include: URI versioning — embed the version in the URL path (/api/v1/orders, /api/v2/orders), which is simple and explicit; Header versioning — pass the version in a request header (Accept: application/vnd.myapp.v2+json), keeping URLs clean; Consumer-driven contract testing (Pact) — automatically verify that new service versions are still compatible with all known consumers; and additive changes only — follow backward-compatible rules: add new fields (never remove or rename), add new endpoints, and make new fields optional. Semantic versioning (MAJOR.MINOR.PATCH) helps communicate the impact of changes to consuming teams.

Backward compatibility means that when a service is updated, existing consumers continue to work without changes. Key practices: Postel's Law ("be conservative in what you send, liberal in what you accept") — ignore unknown fields in incoming messages and never remove or rename existing fields. Additive-only schema changes — add new optional fields rather than changing existing ones. API versioning — maintain old endpoints alongside new ones during a migration window. Consumer-driven contract tests (Pact) — each consumer specifies its expectations in a contract, and the provider's CI pipeline verifies it satisfies all contracts before deployment. Semantic versioning — clearly communicate breaking changes via MAJOR version bumps. Teams at Netflix maintain multiple API versions concurrently to support different client generations.

The CAP theorem states that a distributed system can guarantee at most two of three properties: Consistency (every read receives the most recent write), Availability (every request receives a response, without guarantee it is the latest), and Partition Tolerance (the system continues to function despite network partitions). In microservices, network partitions are inevitable — the network between services will occasionally fail. Therefore, every distributed system must choose between CP (consistency over availability — reject requests when partitioned, like HBase, ZooKeeper) or AP (availability over consistency — serve potentially stale data, like Cassandra, DynamoDB in eventually-consistent mode). Most microservices systems choose AP because user-facing services must remain available, accepting eventual consistency with careful design around stale reads and conflict resolution.

Strong consistency guarantees that all reads see the latest write immediately, but it requires coordination (locks, 2PC) across services, which reduces availability and throughput — and is practically infeasible across independent databases. Eventual consistency means the system will converge to a consistent state given no new updates, but reads may temporarily return stale data. The practical trade-offs are significant: eventual consistency requires designing business processes that tolerate temporary inconsistency (e.g., showing "pending" payment status), implementing idempotency for safe retries, handling out-of-order events, and building compensating logic for conflicts. Strong consistency is appropriate for financial transactions within a single service boundary. Eventual consistency is the pragmatic choice for cross-service data — design your UX and business rules to accommodate it gracefully rather than fighting distributed systems physics.

CRDTs (Conflict-free Replicated Data Types) are data structures designed to be replicated across multiple nodes and merged automatically without conflicts, guaranteeing eventual consistency by mathematical construction. Because all concurrent updates to a CRDT can be merged deterministically — regardless of order — they eliminate the need for coordination or conflict resolution logic. Examples: a G-Counter (grow-only counter, used for view counts) merges by taking the max of each node's value; an LWW-Register (Last-Write-Wins Register) uses timestamps; an OR-Set (Observed-Remove Set) supports add and remove operations. CRDTs are used in databases like Riak, Redis (CRDT data types in Redis Enterprise), and real-time collaborative apps like Figma. In microservices, CRDTs are valuable for high-availability counters, shopping carts, and collaborative features where distributed writes must converge without coordination.

Event Storming is a collaborative workshop technique invented by Alberto Brandolini for rapidly exploring complex business domains and designing microservices boundaries. Domain experts and developers gather around a large paper roll or virtual whiteboard and use colored sticky notes to map out the domain: orange for Domain Events (things that happened, past tense), blue for Commands (actions that trigger events), yellow for Aggregates (the business entities that handle commands), purple for Policies (rules that react to events), and pink for External Systems. As the event flow emerges, natural clusters of tightly related events and aggregates reveal bounded context boundaries and suggest service decompositions. Event Storming collapses months of requirements gathering into a one or two-day session by forcing domain experts and engineers to use a shared language.

Consumer-driven contract testing with Pact is a testing strategy that verifies service-to-service compatibility without requiring live integration environments. The consumer service defines a contract — a specification of the requests it makes and the responses it expects — and Pact generates a mock provider for the consumer's tests. The contract is published to a Pact Broker. The provider service's CI pipeline then verifies it can satisfy all published contracts by replaying the specified requests against its real code. If the provider changes its API in a way that breaks a consumer's contract, the CI pipeline fails before deployment. This gives teams confidence they can deploy services independently without running expensive full-stack integration tests, while still catching breaking API changes early — essential for teams operating hundreds of microservices.

The three pillars of observability — Metrics, Logs, and Traces — together provide the visibility needed to understand system behavior and diagnose problems in a distributed microservices environment. Metrics are aggregated numerical measurements over time (request rate, error rate, latency percentiles, CPU usage) collected by Prometheus and visualized in Grafana — ideal for alerting and trend analysis. Logs are structured (JSON), timestamped records of discrete events emitted by services, shipped to Elasticsearch or Loki — ideal for detailed debugging of specific incidents. Distributed traces (Jaeger, Zipkin, AWS X-Ray) capture the end-to-end journey of a request across services — ideal for understanding latency and service dependencies. Each pillar answers different questions; together they give operators the context to debug issues that would be invisible in isolation.

The Reactive Manifesto describes four principles for building responsive, resilient distributed systems. Responsive: the system responds in a timely manner under all conditions, establishing reliable upper bounds on response time. Resilient: the system stays responsive in the face of failure, achieved through replication, containment, isolation, and delegation — failures are isolated so they don't cascade. Elastic: the system scales automatically under varying workloads by adding or removing resources. Message-driven: components communicate via asynchronous message passing with explicit message boundaries, enabling loose coupling and backpressure. In microservices, these principles translate to: designing stateless, independently scalable services; using circuit breakers and bulkheads for resilience; employing async event-driven communication; and implementing backpressure in stream processing (Reactive Streams, Project Reactor, RxJava).

In choreography, each service reacts to events and publishes new events — there is no central coordinator. Services are maximally decoupled: adding a new step means adding a new subscriber without touching existing services. However, the overall business process is implicit and scattered across many services, making it very hard to visualize, debug, and monitor. In orchestration, a central saga orchestrator explicitly commands each participant in sequence and handles compensating rollbacks centrally. The business process is explicit and visible in one place, making it easy to trace, debug, and modify. The orchestrator becomes a coupling point (changes to the workflow require changing the orchestrator) and a potential bottleneck. For simple workflows with few participants, choreography is clean and scalable. For complex, long-running business processes with many failure modes (like order fulfillment), orchestration's visibility and centralized error handling justify the coupling cost. Many mature systems use both: choreography between bounded contexts, orchestration within a bounded context.

Conway's Law states: "Organizations which design systems are constrained to produce designs which are copies of the communication structures of those organizations." In practice, the architecture of your software mirrors your team structure. If three teams share one codebase, you get a monolith. If each team owns an independent service, you get microservices. The Inverse Conway Maneuver deliberately restructures teams to drive the desired architecture — organize teams around business capabilities (the bounded contexts you want as services) to produce services that match those boundaries. Team Topologies (by Skelton and Pais) extends this with four team types: Stream-aligned teams (own services end-to-end), Enabling teams (help others adopt new practices), Complicated-subsystem teams (own especially complex services), and Platform teams (provide internal infrastructure). Cognitive load is the key constraint — a team can only own what it can fully understand and operate.