Integration Design Patterns: What They Are and Which Ones Tend to Show Up in Interviews

What they are and what they are not

An integration design pattern is a reusable solution to a problem of communication between separate systems: different applications, each with its own network, failures, formats, and response times. Do not confuse it with two other families:

• GoF patterns (Gamma, Helm, Johnson, Vlissides, 1994, 23 patterns): organize classes and objects inside a single process. Examples: Strategy, Factory, Decorator. Observer resembles Publish-Subscribe, but it works in memory, inside one application, with no network, no persistence, and no partial failure.
• Web patterns (such as the presentation patterns in Patterns of Enterprise Application Architecture, Fowler, 2002): structure the layer that handles an application's HTTP requests. Examples: MVC, Front Controller, Page Controller, Template View.
• Integration patterns: deal with what happens between applications. How to deliver a message without losing it, how to route it, how to keep one service's failure from taking down the others, how to keep data consistent without a distributed transaction.

In short, by scale: GoF lives in the code, web lives in the request, integration lives between systems.

Main references

1. Hohpe, G.; Woolf, B. Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions. Addison-Wesley, 2003. A catalog of 65 patterns, centered on messaging and technology-independent.
2. Richardson, C. Microservices Patterns. Manning, 2018. Microservice architecture patterns, including distributed data and resilience. The list below comes from the pattern language at microservices.io (53 patterns), which keeps evolving and may include items added after the 2018 book.

Four patterns that tend to show up in interviews

Publish-Subscribe Channel

(Hohpe and Woolf, Enterprise Integration Patterns)

The producer publishes an event and every subscriber receives a copy, without the producer knowing who they are. The orders service publishes OrderCreated, and inventory, billing, and notifications react independently.

Typical questions: how it differs from Point-to-Point, what happens to an offline subscriber (Durable Subscriber), and how to handle duplicates.

Circuit Breaker

(Richardson, Microservices Patterns)

A proxy counts the failures of a remote service. Past a threshold, the circuit opens and calls fail immediately instead of exhausting threads on timeouts. After a while, it lets a few test calls through (half-open) and closes again if they succeed. This prevents cascading failures.

Typical questions: the three states, how it differs from retry and timeout, and which fallback to use.

Saga

(Richardson, Microservices Patterns)

Replaces the distributed transaction with a sequence of local transactions, plus compensating transactions when a step fails. Create order → reserve stock → charge payment; if the charge fails, the stock is released and the order is canceled. It can be choreographed (services react to events) or orchestrated (a coordinator drives the steps). The cost is eventual consistency.

Typical questions: choreography vs. orchestration, and why not use 2PC.

Transactional Outbox

(Richardson, Microservices Patterns)

Solves the dual write problem: saving to the database and publishing to the broker without only one of the two happening. The message is written to an outbox table in the same local transaction as the business data, and a relay publishes it later, by polling (Polling Publisher) or by reading the database log (Transaction Log Tailing, as Debezium does). Delivery is at-least-once, so the consumer must be idempotent.

Typical questions: why not publish right after the commit, and how to avoid duplicates.

These four are a selection based on market experience, not a sourced ranking.

List: Enterprise Integration Patterns (65)

Source: Hohpe, G.; Woolf, B. Enterprise Integration Patterns. Addison-Wesley, 2003.

• Integration styles: File Transfer, Shared Database, Remote Procedure Invocation, Messaging
• Messaging systems: Message Channel, Message, Pipes and Filters, Message Router, Message Translator, Message Endpoint
• Channels: Point-to-Point Channel, Publish-Subscribe Channel, Datatype Channel, Invalid Message Channel, Dead Letter Channel, Guaranteed Delivery, Channel Adapter, Messaging Bridge, Message Bus
• Message construction: Command Message, Document Message, Event Message, Request-Reply, Return Address, Correlation Identifier, Message Sequence, Message Expiration, Format Indicator
• Routing: Content-Based Router, Message Filter, Dynamic Router, Recipient List, Splitter, Aggregator, Resequencer, Composed Message Processor, Scatter-Gather, Routing Slip, Process Manager, Message Broker
• Transformation: Envelope Wrapper, Content Enricher, Content Filter, Claim Check, Normalizer, Canonical Data Model
• Endpoints: Messaging Gateway, Messaging Mapper, Transactional Client, Polling Consumer, Event-Driven Consumer, Competing Consumers, Message Dispatcher, Selective Consumer, Durable Subscriber, Idempotent Receiver, Service Activator
• System management: Control Bus, Detour, Wire Tap, Message History, Message Store, Smart Proxy, Test Message, Channel Purger

List: Microservices Patterns (53)

Source: Richardson, C. Microservices Patterns. Manning, 2018, as listed in the pattern language at microservices.io (which may include items added after the book).

• Architectural style: Monolithic Architecture, Microservice Architecture
• Service boundaries: Decompose by Business Capability, Decompose by Subdomain, Self-contained Service, Service per Team
• Refactoring: Strangler Application, Anti-corruption Layer
• Service collaboration: Database per Service, Shared Database, Saga, Command-side Replica, API Composition, CQRS, Domain Event, Event Sourcing
• Transactional messaging: Transactional Outbox, Transaction Log Tailing, Polling Publisher
• Testing: Consumer-driven Contract Test, Consumer-side Contract Test, Service Component Test
• Deployment: Multiple Service Instances per Host, Service Instance per Host, Service Instance per VM, Service Instance per Container, Serverless Deployment, Service Deployment Platform
• Cross-cutting concerns: Microservice Chassis, Externalized Configuration, Service Template
• Communication: Remote Procedure Invocation, Messaging, Domain-specific Protocol, Idempotent Consumer
• External API: API Gateway, Backend for Front-end
• Service discovery: Client-side Discovery, Server-side Discovery, Service Registry, Self Registration, 3rd Party Registration
• Reliability: Circuit Breaker
• Security: Access Token
• Observability: Log Aggregation, Application Metrics, Audit Logging, Distributed Tracing, Exception Tracking, Health Check API, Log Deployments and Changes
• UI: Server-side Page Fragment Composition, Client-side UI Composition