# Integration Architecture Patterns
Integration architecture is about how real enterprises connect systems that were never designed to talk to each other. Here are the core patterns, in the order most platforms grow into them.
## Point-to-Point
One system calls another directly, hardcoded and tightly coupled. Works fine with two or three systems. Add a fourth, fifth, sixth, and you get a spaghetti diagram nobody wants to touch.
## API-Led Connectivity
This is where structure replaces spaghetti. Instead of systems reaching into each other directly, introduce three layers:
- **System APIs** — unlock data from the backend
- **Process APIs** — combine and orchestrate that data
- **Experience APIs** — shape it for a specific consumer (mobile, web, partner)
The backend can change underneath, and consumers never feel it.
## API Gateway + Load Balancing
Layers solve structure, but traffic keeps growing, and a single API instance becomes a bottleneck. The gateway gives every consumer a single entry point into the platform, distributes requests across workers, enforces policies, and stops one noisy consumer from taking down the platform for everyone else.
## Cache-Aside
Even with traffic spread across instances, every request still hits the source system, and backends were never built for that frequency. Caching frequently requested reference data close to the consumer cuts latency and protects those systems. Tradeoff: cached data goes stale, so freshness and invalidation become real design decisions.
## Canonical Data Model
Faster data movement exposes the next problem: every system speaks its own format. A canonical model gives every system one common format to map into, instead of translating point-to-point between every pair of systems. Tradeoff: if the canonical model grows too large, it becomes a bottleneck of its own — every change touches everyone — so mature platforms evolve it per domain rather than as one giant enterprise model.
## Domain-Aligned APIs (Microservices Principle)
API-led gives you layers, but layers alone don't guarantee independence. Teams often bundle many APIs into one large deployable, or let a single Process API grow to orchestrate everything — the layers exist on paper, but deployment is still coupled. Aligning APIs to business domains, each deployed and scaled independently, means a change to one capability doesn't force a redeploy of everything else.
Get Shanthip’s stories in your inbox
Join Medium for free to get updates from this writer.
## Event-Driven Architecture (Pub-Sub / Message Queue)
More services means more service-to-service calls. Some must be synchronous — a real-time lookup can't wait. But synchronous chains are dangerous under load, since one slow system delays everything behind it. Asynchronous communication breaks that chain: publish an event, and downstream systems consume it independently, at their own pace. This also improves scalability — producers and consumers scale independently of each other. But async brings a new reality: messages can be delivered more than once.
## Idempotency
Retries, duplicate deliveries, and client timeouts mean the same request can arrive multiple times. Idempotency ensures processing it once or ten times produces the same result — no duplicate orders, payments, or records. It's especially critical for payment, order, and event-driven integrations, and it's what makes the next pattern safe to use.
## Circuit Breaker + Retry with Backoff
In distributed systems, failures aren't the exception — they're the default assumption. A circuit breaker stops hammering a struggling downstream system. Retry with backoff gives transient failures a chance to resolve instead of cascading. Two rules keep retries safe: retry only transient failures, and only against idempotent operations — otherwise retries create duplicate processing instead of resilience.
## Security: OAuth 2.0, mTLS, Rate Limiting
Circuit breakers and retries protect the platform from internal failures — but every API you expose is also a door someone can knock on. Security has to thread through every layer:
- **OAuth 2.0** — verify who the consumer is and what they're allowed to call
- **Mutual TLS** — both sides prove their identity, and traffic is encrypted in transit
- **Rate Limiting / Throttling** — one consumer can't overwhelm the shared platform, intentionally or not
Not bolted on at the end — designed in from the start.
## Observability
So now the platform is layered, decoupled, resilient, and secured. But when a request fails somewhere across five APIs, an event broker, and three backends — how do you find where? That's observability:
- **Correlation IDs** — one ID follows the request across every hop
- **Centralized logging** — what happened, in one searchable place
- **Distributed tracing** — where the time went and where the failure started
Without it, debugging a distributed platform at 2 a.m. is guesswork.
## Dead Letter Queue + Graceful Degradation
Observability tells you what broke. These two patterns decide what happens to the work while it's broken:
- **Dead Letter Queue** — a message that keeps failing isn't lost or retried forever; it's parked in a separate queue for inspection and replay
- **Graceful Degradation** — the platform serves partial functionality instead of failing completely. An e-commerce site keeps showing products even if recommendations are temporarily down — users feel a slowdown, not an outage
---
Notice that each pattern solves the limitation introduced by the previous one. Enterprise integration isn't about using every pattern from day one — it's about introducing the next pattern only when scale, complexity, or reliability demands it.
That's the difference between a set of connected APIs and a resilient integration platform.
