Shopify integration architecture: middleware or direct?

At some point every growing store faces this: Shopify needs to talk to an ERP, a warehouse system, an accounting package and a CRM. Do you build four direct connections, or put something in the middle?

The answer is mostly determined by counting.

The counting test

Two systems: connect them directly. Middleware adds a component, a cost and a place for things to break, for no benefit at this size.

Three systems: usually still direct, if the connections are simple and one-directional.

Four or more, or several bidirectional: middleware. Point-to-point connections grow as roughly the square of the number of systems. Four systems fully connected is twelve one-way flows, each with its own retries, its own mapping and its own failure modes. Nobody can reason about that, and nobody wants to be the person who inherits it.

What direct integration gives you

• Fewer moving parts. One thing to deploy, monitor and debug.
• Lower cost. No platform subscription, no extra hosting.
• Full control over the logic, the timing and the error handling.
• No vendor between you and your data.

And what it costs:

• Logic duplicated across connections — every one needs its own retries, backoff and error handling.
• No single view. When something goes wrong, you check four places.
• Fragile to change. Replace the ERP and every connection touching it is rewritten.

What middleware gives you

Whether it's an integration platform or something you build:

• One place for mapping and transformation, so a field rename happens once.
• One place for retries, queueing and dead letters.
• Observability. A single log of what moved, when, and what failed. This is usually the biggest practical win.
• Decoupling. Systems talk to the middleware, not to each other, so replacing one affects one connection.
• Buffering. A system being down doesn't lose data; it queues.

And what it costs:

• Another component to run, monitor and pay for.
• Latency, usually irrelevant, occasionally not.
• Lock-in if it's a platform with its own configuration language.
• A skills dependency on whoever knows it.

Build or buy the middle

Integration platforms — the ones that connect common systems with prebuilt connectors — are worth trying first when your systems are mainstream. Fastest to working, and someone else maintains the connectors.

Custom middleware — a service you write, with a queue, a database and workers — makes sense when your transformation logic is genuinely specific, when the platforms don't have connectors for your systems, or when data can't leave your infrastructure.

The honest middle answer, and the most common one in practice: a platform for the standard flows, custom code for the two or three things that make your business specific. Same pattern as ERP integration and accounting.

What doesn't change either way

Whatever the architecture, these are non-negotiable and are where integrations actually fail:

• One owner per field, written down. The single most important decision, and it's a business decision, not a technical one.
• Idempotent operations, because retries and at-least-once webhooks guarantee duplicates.
• A reconciliation job comparing both sides on a schedule.
• Errors visible to a person who can act, ideally in the Shopify admin.
• Logs sufficient to answer what happened to a specific order.

Middleware makes several of these easier to implement in one place. It doesn't make any of them optional.

A migration path that works

You don't have to choose up front:

1. Start direct with the first, highest-value connection — usually inventory or orders.
2. Add the second directly too, if it's simple.
3. When the third arrives, or when the second becomes bidirectional, extract the shared concerns — retries, mapping, logging — into a common layer.
4. That layer is your middleware, grown from real requirements rather than guessed at.

This is nearly always cheaper than starting with a platform you don't yet need, and considerably cheaper than a four-way point-to-point mesh you refactor under pressure.

Middleware isn't better architecture. It's what you buy when the number of connections passes the point where a person can hold them all in their head.