Microservices Architecture Patterns Vocabulary

Circuit breaker pattern: a resilience pattern that wraps calls to a remote service and monitors for failures. States: Closed — normal operation; requests flow through; failures are counted. Open — failure threshold exceeded; all requests fail immediately (fast fail) without calling the downstream service; a fallback response is returned. Half-open — after a recovery timeout, a limited number of probe requests are allowed through; if they succeed, circuit closes; if they fail, circuit reopens. Problem solved: without a circuit breaker, a slow/failing service causes all callers to wait for timeouts, exhausting thread pools and causing cascading failures across the system. Libraries: Resilience4j (Java), Polly (.NET), Hystrix (deprecated but influential). Related patterns: Bulkhead — isolate resources (thread pools, connection pools) per downstream service so one service's failure doesn't exhaust all resources. Timeout — always set explicit timeouts on remote calls. Retry with exponential back-off — retry failed requests with increasing delays (1s, 2s, 4s, 8s) + jitter to avoid thundering herd. In conversation: "After the database brownout, the circuit opened on 6 services — they all returned cached responses instead of timing out, which is why users saw stale data rather than errors."

Saga pattern: manages distributed transactions across multiple services, each owning its own database (no shared DB). A saga is a sequence of local transactions. Each step either succeeds or triggers a compensating transaction to undo previous steps. Saga approaches: Choreography — services react to events; no central coordinator. Service A completes → publishes "A completed" event → Service B listens and starts → publishes "B completed" → etc. Pros: loose coupling. Cons: hard to track overall flow; risk of cyclic dependencies. Orchestration — a central saga orchestrator (a dedicated service or workflow engine) sends commands and awaits replies. Pros: clear flow; easy to monitor. Cons: orchestrator becomes a potential single point of failure; tighter coupling. Compensating transaction: the undo operation for a completed local transaction. Example: if payment succeeds but inventory reservation fails, the compensating transaction refunds the payment. Idempotent consumer: a message consumer that produces the same result whether it processes a message once or multiple times (needed because messages can be redelivered). Tools: Temporal, AWS Step Functions, Axon Framework, Conductor. In conversation: "We chose orchestration for the checkout saga because the business logic is complex enough that we need visibility into which step failed."

Outbox pattern: solves the dual write problem (updating a DB + publishing an event atomically). Implementation: 1) Write the business data AND an outbox record in the same database transaction (atomic). 2) A separate transactional outbox publisher reads the outbox table and publishes events to the message broker. 3) Marks outbox records as published. The outbox table is in the same DB as the business data — so the write is always atomic. Transactional outbox: the canonical name. Change Data Capture (CDC): an alternative implementation where a CDC tool (Debezium, AWS DMS) reads the database WAL (write-ahead log) and streams changes to Kafka — without a separate outbox table. At-least-once delivery: messages may be delivered more than once; consumers must be idempotent. Exactly-once semantics: harder to achieve; Kafka Transactions + idempotent producer come close. Inbox pattern: the consumer-side complement — stores received messages in an inbox table before processing, enabling deduplication. In conversation: "Before the outbox pattern, we had race conditions where the DB committed but the Kafka publish failed — customers were charged but orders weren't created."

Strangler fig pattern (Martin Fowler): named after the strangler fig tree that grows around a host tree and eventually replaces it. Applied to software migrations: 1) Put a proxy/facade in front of the monolith. 2) Build new functionality in the new system. 3) Migrate existing functionality module by module, redirecting traffic at the proxy. 4) When all functionality is migrated, decommission the monolith. Migration pattern vocabulary: Anti-corruption layer (ACL) — a translation layer between the old system's model and the new system's domain model; prevents the old system's concepts from "corrupting" the new design. Branch by abstraction — introduce an abstraction layer over the component being replaced; then implement the new version behind the abstraction; switch over when ready. Parallel run — run old and new implementations simultaneously; compare outputs to validate correctness before switching. Facade — a simplified interface over a complex or legacy subsystem; used in strangler fig to intercept and redirect calls. In conversation: "We've been strangling the monolith for 8 months — the order management module is fully migrated, checkout is 60% done, and only the legacy reporting module is still in the monolith."

Bounded context: one of the central patterns in Domain-Driven Design (DDD, Eric Evans). An explicit boundary within which a domain model applies consistently. Inside a bounded context, all terms have one agreed meaning. DDD vocabulary: Ubiquitous language — a shared vocabulary used by both domain experts and engineers within a bounded context. Code, tests, and conversations all use the same terms. Context map — a diagram showing all bounded contexts and their integration relationships. Integration patterns: Shared Kernel, Customer-Supplier, Conformist, Anti-Corruption Layer, Open Host Service, Published Language. Aggregate root — a cluster of domain objects treated as a single unit for data changes. External objects reference the aggregate only through its root. Example: Order (root) + OrderItems + ShippingAddress — all change together. Domain event — something meaningful that happened in the domain: OrderPlaced, PaymentProcessed, InventoryReserved. Value object — an object defined by its attributes, not its identity. Example: Money(amount=100, currency="USD") — no ID needed. In conversation: "Before we defined bounded contexts, 'product' meant something different to the catalogue team (a listing) versus the warehouse team (a physical SKU) — we had constant integration bugs."

The question focuses on Alice's problem description within a microservices context. She's using event sourcing – publishing events and having other services react – which is precisely what the pattern entails. Options A and D are incorrect because they represent alternative approaches to data consistency or system design principles. Option C describes a *tool* for asynchronous communication, not the core pattern itself.

The API Composition pattern focuses on creating new services that combine the functionality of existing ones. This is represented by the 'UserSummary' service which aggregates data from other services – a core aspect of the pattern's goal: to expose combined functionality through a single interface. Options A and C are related but don't describe the primary purpose, while D describes scaling strategies.

The core defining feature of the Choreography approach is its decentralized nature. Services independently react to events without a central controller managing the flow – this creates an autonomous chain of actions. Options A and C are incorrect as they describe alternative approaches or limitations. Option D is factually inaccurate regarding the Saga pattern's applicability.

The error message – a full outbox queue – directly points to the problem. The outbox pattern relies on a separate process reading and publishing events; if this process fails or is overwhelmed (due to high volume), the queue will fill up. Options B and C are potential issues but don't explain why the *queue* is full. Option D contradicts the intended behavior of an outbox implementation.

The core principle of CQRS is to separate command and query responsibilities. This allows each side to be optimized independently – relational databases are well-suited for transactions (commands), while NoSQL databases excel at read-heavy operations (queries). Option C is incorrect as it describes a different consistency strategy, and option D focuses on development processes instead of architectural benefits.