5 Data Integration Patterns Every Business Should Know

Once a business runs on more than a few apps, the same customer, order or product lives in several systems, and sooner or later they disagree. How you connect those systems matters more than which tool you use. These are the five patterns we use most, when each one fits, and how to build it with n8n.

1. Point-to-point

Two systems connected directly: when something happens in A, update B. A new Shopify order creates a row in Google Sheets; a closed deal in HubSpot creates a customer in QuickBooks.

When it fits: a few systems, modest volume and stable APIs. It is the fastest way to remove a manual step.

Watch out for: sprawl. Every new system can need a link to each existing one, so adding the Nth system can mean N-1 new connections, each with its own field mapping and failure modes. Five systems that all talk to each other can need ten links.

In n8n: one workflow per link. Trigger in system A, map fields with a Set node, write to system B and point failures at a shared error workflow.

2. Hub-and-spoke

Every system connects to a central hub instead of to each other. The hub holds the mappings and often the master copy of shared records, such as customers or products.

When it fits: three or more systems exchange the same entities. Each system needs only one connection, to the hub, and a new system plugs in without touching the others.

Watch out for: the hub becomes critical. It needs an owner, monitoring and a clear canonical format for each entity.

In n8n: either n8n is the hub, receiving changes from each system, converting them to one standard shape and writing them to the others, or the hub is a database such as Postgres and n8n moves records in and out of it.

3. Publish-subscribe

A system publishes an event, such as "order placed", to a topic on a message broker. Any number of subscribers receive it and act independently: one creates the invoice, one updates inventory, one sends the confirmation email.

When it fits: one event needs many reactions, and you want to add new reactions without changing the system that publishes. Common brokers include Kafka, RabbitMQ, Amazon SNS and SQS, and Google Pub/Sub.

Watch out for: messages can arrive twice or out of order, so every subscriber must be safe to run more than once. You also need to run or pay for the broker.

In n8n: trigger nodes for Kafka, RabbitMQ, MQTT and others let a workflow subscribe to a topic. Without a broker, a simpler version is a dispatcher workflow that receives the event once and calls a sub-workflow for each reaction.

4. ETL and ELT (batch)

Extract data from source systems on a schedule, transform it and load it into a destination, usually a warehouse for reporting. In ELT, raw data is loaded first and transformed inside the warehouse.

When it fits: analytics, reporting, backfills and large volumes, where data that is a few minutes or hours old is fine.

Watch out for: stale data between runs, and API rate limits. Load only what changed since the last run, using an "updated since" cursor you store after each successful run.

In n8n: Schedule trigger → fetch records changed since the stored cursor → process them in batches with Loop Over Items → transform → load into Postgres, BigQuery or Snowflake → save the new cursor → alert on failure. For very large tables, a dedicated ELT tool may be the better engine, with n8n orchestrating around it.

5. Event-driven (real time)

Systems react to changes the moment they happen, usually through webhooks or change data capture. A form submission routes a lead in seconds; a failed payment opens a task before the customer notices.

When it fits: actions that cannot wait, such as lead routing, fraud signals, stock updates and support escalations.

Watch out for: webhooks can arrive twice, out of order or not at all. Verify signatures, ignore event IDs you have already processed, and run a scheduled sync that catches anything missed.

In n8n: a Webhook node or app trigger receives the event and responds quickly, a check against a database skips duplicates, and heavier work moves to a sub-workflow. Queue mode with workers keeps busy webhooks responsive.

The patterns side by side

Pattern	Freshness	Best for	Main risk
Point-to-point	Real time or scheduled	Two or three systems, simple syncs	Sprawl as systems grow
Hub-and-spoke	Either	Shared records across many systems	The hub becomes a single point of failure
Publish-subscribe	Near real time	One event, many reactions	Duplicates and ordering
ETL and ELT	Minutes to hours	Reporting, analytics, backfills	Stale data between runs
Event-driven	Seconds	Time-sensitive actions	Missed or repeated events

Choosing a pattern

Answer these for each flow of data:

• How fresh must it be? Seconds points to event-driven; hours points to batch.
• What happens if a record is lost or duplicated? If neither is acceptable, plan for idempotency, retries and a dead-letter store from day one.
• Which system owns each record? Every entity needs one source of truth.
• How many systems share it? Three or more is the signal to move from point-to-point to a hub.
• How much data, how often? High volume favors batches and brokers over one-by-one API calls.

Most real setups combine patterns. A common one: event-driven for urgent actions, a nightly batch that reconciles anything missed, and a hub for customer and product master data.

Practices that apply to every pattern

• Data contracts. Document each entity's fields, formats, owner and source of truth, so sales, finance and analytics mean the same thing by "customer".
• Idempotency. Store external IDs and use upserts, so running a sync twice never creates duplicates.
• Dead letters. Send records that fail to a holding table with the error, so they can be fixed and replayed instead of lost.
• Monitoring. Alert on failed runs, track record counts per run and compare totals between systems on a schedule.
• Least privilege. Use service accounts with only the access each integration needs.

Get help with your integrations

Our data integration team designs and builds these patterns on n8n, and API integration covers connecting systems that have no ready-made node. See how we work with PostgreSQL and MySQL.