Software architecture · Level 4: Communication and integration · Module 18 of 46

Integration styles

Sooner or later every system has to exchange data with another one: a warehouse, a payment provider, a decades-old ERP, a partner's platform. There are only four basic ways to do it, and each has been in use for decades because each is the right answer somewhere. Knowing them, and the handful of patterns that glue systems together, saves you from choosing integration by habit.

1. The idea

Four ways for two offices to share information. They can post each other a box of paperwork every night (file transfer). They can both work out of the same filing cabinet (shared database). They can phone each other and wait on the line for an answer (remote procedure call). Or they can drop notes in each other's in-tray to be dealt with when there's time (messaging). Each works; each fails in a different way.

Style	How it works	Strengths	Weaknesses
File transfer	One system writes a file (CSV, XML, fixed-width) on a schedule; the other picks it up and imports it	Simple, works with almost any system, great for bulk data	Data is hours old; format changes break silently; partial files and duplicates
Shared database	Both systems read and write the same tables	Always consistent, no copying, easy queries	Couples both systems to one schema; neither can change it alone
Remote procedure call	One system calls the other's API (REST, gRPC, SOAP) and waits for the answer	Immediate answer, familiar, easy to reason about	Both must be up at the same time; the caller is as slow as the callee
Messaging	One system sends a message to a queue or topic; the other processes it when it can	Decoupled in time; absorbs bursts; survives outages	Eventual consistency; harder to debug; needs a broker

The deepest difference is temporal coupling: whether both systems must be running and responsive at the same moment. RPC requires it; file transfer and messaging don't; a shared database couples the systems through structure instead of time.

2. How it works

One integration, four ways

A shop must tell its warehouse about new orders. Watch each style deliver an order, then fail.

An integration hub and its patterns

When many systems with different formats must talk, a hub in the middle translates and routes messages so each system speaks only one format. Watch three of the classic integration patterns at work.

Pattern	What it does
Translator	Converts one format into another (CSV to JSON, an old schema to a new one)
Content-based router	Sends each message to a destination chosen from its content (country, order type)
Splitter and aggregator	Breaks a batch into individual messages, or combines related messages into one
Content enricher	Adds missing data from another source before passing a message on
Canonical data model	One shared format in the hub, so each system needs one translator instead of one per partner

3. Try it yourself

Which style fits this integration?

Describe the integration and see the four styles ranked. Change one answer at a time to see which requirement drives the choice.

4. Trade-offs

Freshness vs decoupling

RPC and a shared database give the latest data instantly but couple the systems tightly. File transfer and messaging decouple them, and the data is minutes or hours behind.

Bulk vs individual

Files move millions of records cheaply; messages and calls handle one record at a time with low latency. Many integrations use both: messages for changes, a nightly file to reconcile.

Direct vs through a hub

Direct integrations are simple for two systems, and become a tangle of N × (N − 1) connections for many. A hub needs only one connection per system, and becomes a central dependency.

Their format vs a canonical one

Translating straight between each pair is quick at first; a canonical format costs a design effort up front and pays off as partners multiply.

5. In real projects

File transfer is alive and well. Banks, payroll providers, logistics partners and government systems still exchange files, often over SFTP or object storage, because it's universal and handles huge volumes. Make imports idempotent, validate before loading, and alert when a file is late or malformed.

Shared databases between systems are the integration style most likely to cause pain later: neither system can change its schema without the other. If you must, expose read-only views and treat them as a contract.

Integration hubs (iPaaS products, open-source integration frameworks, or an ESB used as one) earn their place when many packaged systems with different protocols must connect. Keep business rules out of them; keep translations and routing in.

Say it in the interview

Two-sentence answers

"What are the integration styles?" File transfer, shared database, remote procedure call and messaging. They differ mainly in freshness and in how tightly they couple the systems, in time or in structure.
"Integrating with a legacy system that only exports CSV nightly?" File transfer, with idempotent imports, validation and an alert when the file is late. If we need fresher data later, add change messages on top.
"Why avoid a shared database between systems?" It couples both to one schema, so neither can change its data model alone. An API or messages make the contract explicit and changeable.

Red flags interviewers notice

Using RPC to a partner that's often down, with no retry or queue.
"Just read their database" as an integration plan.
Business rules hidden in an integration hub's mappings.

6. Remember it

Memory hook: "Post, cabinet, phone, in-tray"The four ways offices share information, and the four integration styles: file, shared database, RPC, messaging.

How this hook works: what "post, cabinet, phone, in-tray" means

What the slogan means, phrase by phrase

"Post": File transfer: a batch, on a schedule, read later.
"cabinet": Shared database: one store, both sides depend on its layout.
"phone": RPC: both must be there at once; you wait for the answer.
"in-tray": Messaging: drop it off, it's handled when the other side is ready.

Why this picture fits: everyone already knows how each of these fails in an office: lost post, a reorganised cabinet, nobody answering, a full in-tray.

The story → the concept

Office	Integration
Nightly box of paperwork	Batch file transfer
Somebody reorders the cabinet	A schema change breaks the other system
The other office is closed	RPC fails when the callee is down
The in-tray fills up	Queue depth grows; consumers catch up later

The trap it saves you from

Using the same integration style for everything because it's the one the team knows.

7. Common mistakes

Integrating through another system's tablesQuick to build and the hardest coupling to undo. Neither system can change its schema alone.

Non-idempotent file importsA file imported twice, or a partial file, duplicates or loses records. Track file IDs and validate before loading.

Synchronous calls to unreliable partnersYour checkout shouldn't fail because a partner's API is down. Queue it.

Point-to-point sprawlTen systems each translating to each other's format: 90 translations. Consider a hub or a canonical model.

8. Design exercise (30 minutes)

Inventory your integrations (10 min). List every system yours exchanges data with, and which style each uses.
Challenge one (10 min). Pick the integration that fails most often. Would a different style fit its real requirements better?
Design the failure path (10 min). For one integration, write what happens when the other side is down for an hour, and how data catches up.

9. Self-check quiz

Which style requires both systems to be up at the same moment?

The caller waits for the callee's answer: temporal coupling.

What's the main risk of integrating through a shared database?

Neither can change the data model without the other.

Two million payroll records must go to a bank once a day. Which style?

Bulk, scheduled, between organisations: what files are for.

Which pattern sends each message to a destination chosen from its content?

For example, orders routed to a warehouse by country.

What does a canonical data model in a hub save?

N translators instead of up to N × (N − 1).

10. Go deeper

Resource	Time	Why
Integration Styles (Hohpe and Woolf)	20 min	The four styles as originally described, with their forces.
Enterprise Integration Patterns catalogue	browse	Routers, translators, splitters, aggregators and the rest.
Apache Camel EIPs	browse	The same patterns implemented in a widely used open-source integration framework.