Microservices Architecture Patterns

A resilience pattern that monitors failures to a dependency and, after a threshold is reached, opens the circuit to stop sending requests — preventing cascade failures. States: closed (normal), open (failing), half-open (testing recovery).

"The circuit breaker to our payment provider opened after 10 consecutive timeouts — instead of piling up 5,000 blocked threads waiting for a dead service, we returned graceful errors immediately while the provider recovered."

A pattern for managing distributed transactions across microservices using a sequence of local transactions with compensating transactions (rollbacks) for failure cases — avoiding the need for distributed ACID transactions.

"Order placement uses a saga: place order (OrderService) → reserve inventory (InventoryService) → charge payment (PaymentService). If payment fails, compensating transactions cancel the inventory reservation and order."

A pattern for reliably publishing events alongside database changes by writing the event to an outbox table in the same database transaction, then having a separate process publish it to the message broker — guaranteeing exactly-once event publishing.

"The outbox pattern solved our "payment processed but event not published" race condition: the charge and the PaymentProcessed event are written atomically to Postgres, and a Debezium CDC connector publishes the event from the outbox table."

A migration pattern for incrementally replacing a monolith: new functionality is built in new services while a facade routes traffic — over time the monolith is "strangled" as functionality is migrated away.

"We used the strangler fig to migrate from the Rails monolith: a Kong API gateway routes /api/orders to the new Order microservice while all other paths still hit the monolith — no big bang rewrite required."

A Domain-Driven Design pattern defining the boundary within which a particular domain model applies — inside the boundary, all terms have precise meanings; across boundaries, terms may differ or require translation.

"In our system, 'Customer' means different things: in the CRM bounded context it includes sales history, in the billing context it means payment method and plan. Clear bounded contexts prevent model pollution across services."

A message consumer that can safely process the same message multiple times without causing duplicate side effects — essential in distributed systems where at-least-once message delivery guarantees duplicates.

"Our email sending consumer is idempotent: it checks if a notification_id has already been processed before sending — duplicate Kafka messages during broker failover don't cause double emails."

A translation layer at a bounded context boundary that converts between the models of two systems — preventing the domain model of one context from being "corrupted" by the model of an external system.

"Our ACL translates the legacy ERP's order format into our domain model before any bounded context consumes it — changes to the ERP's API only require updating the ACL, not every downstream service."

A business operation that semantically reverses a previously completed transaction in a saga — it cannot technically undo a committed transaction but achieves the same business outcome.

"If the InventoryService reservation succeeds but PaymentService fails, the compensating transaction sends a ReleaseInventory command — restoring stock levels without being a database-level rollback."