Integration is where enterprise architecture either delivers on its promise or quietly accumulates the debt that slows every future change. As estates grow more distributed, the question is no longer whether to integrate but which pattern fits each connection between systems. This field guide covers the main integration patterns for 2026, APIs, events, batch and workflow orchestration, and offers practical guidance on choosing among them rather than defaulting to whatever is familiar.
Why pattern choice matters more than tooling
Organisations often choose an integration tool first and then bend every problem to fit it. The result is event streaming used for things that should be simple requests, or nightly batch jobs propping up processes that need to be real time. The pattern, the shape of the interaction between systems, is the decision that determines whether integration is robust and maintainable. Tooling implements the pattern; it does not substitute for choosing the right one.
Each pattern carries a different set of trade-offs in coupling, latency, consistency and operational complexity. Choosing well means matching those trade-offs to the requirements of the specific connection. A mature integration strategy is therefore not a single technology but a small set of well-understood patterns, each with clear guidance on when to use it, supported by the tools that implement them.
Synchronous APIs: request and response done well
The request and response API remains the workhorse of integration, and rightly so. When a caller needs an answer immediately and the interaction is naturally a question expecting a reply, a synchronous API is the simplest and clearest choice. The discipline that separates good API integration from bad lies in contract design, versioning, error handling and resilience.
Design APIs around stable contracts that hide internal implementation, so that consumers depend on the interface rather than the internals. Version deliberately and avoid breaking changes that ripple across consumers. Build in resilience: timeouts, retries with sensible backoff, and circuit breakers so that a slow dependency does not cascade into a wider outage. The common failure is treating an API as a thin wrapper over a database, which leaks internal structure and creates tight coupling that becomes painful to change.
Events: decoupling through what has happened
Event-driven integration shifts the model from asking for data to being told when something has happened. A producing system emits events, and any number of consumers react without the producer needing to know they exist. This decoupling is powerful: it lets systems evolve independently and supports patterns that synchronous calls handle poorly, such as fanning out a single change to many interested parties.
The trade-off is complexity in reasoning about consistency and ordering. Events are asynchronous, so consumers see the world slightly behind reality, and handling duplicates, ordering and failures requires care. Use events when loose coupling and reactivity matter, when one occurrence has many interested consumers, or when you want to avoid the brittle dependencies that point-to-point synchronous calls create. Do not reach for events when a simple request and response would do, because the operational and cognitive overhead is real.
Batch: still the right answer more often than fashion admits
Batch integration is unfashionable, but it remains the correct choice for a wide class of problems. When you are moving large volumes of data, when the consuming process is inherently periodic, or when real-time freshness adds cost without adding value, batch is simpler, cheaper and easier to operate than streaming alternatives. Reconciliation, large data transfers and many reporting feeds are naturally batch-shaped.
The mistake organisations make is at the extremes: forcing batch onto processes that genuinely need timeliness, or replacing perfectly good batch jobs with streaming infrastructure that adds complexity for no benefit. Choose batch deliberately where its characteristics fit, and modernise it with proper scheduling, idempotency and observability rather than dismissing it as legacy. A well-run batch process is often the most reliable integration you have.
Workflow orchestration: coordinating long-running processes
Some integrations are not a single interaction but a sequence of steps spanning multiple systems and stretching over time, often with human decisions in between. Workflow orchestration manages these long-running processes: it coordinates the steps, handles failures and compensations, and maintains the state of the process so that it can survive interruptions. This pattern suits business processes such as onboarding, fulfilment or approvals that cross several systems.
The key decision is between orchestration, where a central coordinator directs the steps, and choreography, where each system reacts to events without a central conductor. Orchestration gives visibility and explicit control at the cost of a central component to maintain. Choreography is more decoupled but harder to observe and reason about end to end. Choose based on how important central visibility and control are for the process in question, and resist orchestrating everything by reflex.
Choosing the right pattern
- Use synchronous APIs when the caller needs an immediate answer, and invest in stable contracts, versioning and resilience.
- Use events when loose coupling matters or one occurrence has many consumers, accepting the asynchronous complexity.
- Use batch for large volumes, naturally periodic processes and feeds where real-time freshness adds no value.
- Use workflow orchestration for long-running, multi-system processes that need coordination and state.
- Decide between orchestration and choreography based on how much central visibility and control the process requires.
- Standardise on a small set of well-understood patterns with clear guidance on when each applies.
Common pitfalls
The dominant pitfall is letting tooling dictate the pattern, so that every problem is solved with whichever platform the organisation has already bought. This produces integrations that fight their own nature: events where requests belong, batch where timeliness is needed, orchestration where simple choreography would suffice. A second pitfall is inconsistency, where every team invents its own approach and the estate becomes an unintelligible web of bespoke connections.
A third trap is neglecting the operational dimensions of integration: monitoring, error handling, idempotency and the ability to replay or reprocess when something fails. An integration that works on a good day but cannot be diagnosed or recovered on a bad one is a liability regardless of how elegant its pattern. Treat resilience and observability as part of the pattern, not as afterthoughts.
Integration succeeds when each connection uses the pattern that fits its trade-offs, drawn from a small and well-understood set. Need support applying this approach? Email sales@halfteck.com.