TL;DR. Four integration architecture patterns matter for SMBs: point-to-point (every tool wired directly to every other tool — fine at 3, ugly at 8), hub-and-spoke (one iPaaS is the central router — the right answer for ~80% of SMBs), mesh (event-driven pub/sub — only when volume or velocity demands it), and ESB (enterprise service bus — almost never for an SMB). Pick by counting tools, volume, and how fast your workflows change. Migration path for most SMBs: point-to-point → hub-and-spoke.
The question doesn't usually arrive in those words. What we hear on Stack Audits is: "We've got Zapier, but we also have direct connections from Shopify into QuickBooks, and a few from HubSpot to Slack, and I'm not sure who set up which one. It works, mostly. Is this how it's supposed to look?"
The answer is no. Every integrated stack has a topology — a shape data flows through — and you either choose one or you accidentally end up with one. SMBs almost always pick the second route. They wire pairs as needs arise, then discover three years in that they're running point-to-point sprawl that breaks the moment you cross 7 or 8 connected systems.
This article names the four integration architecture patterns that matter and gives you the decision tree for picking yours. It's the architecture companion to our systems integration guide, our iPaaS vs. custom integrations buyer's guide, and the why integrations break in year 2 durability piece. Topology is the call you make before the iPaaS choice.
Why integration topology matters even for an SMB
Topology matters because the number of possible connections grows much faster than the number of tools. Five tools can have ten connections. Ten tools can have forty-five. Fifteen tools — the upper end we see in $1M–$20M SMBs — can have a hundred and five.
This is the same N² problem Fred Brooks named in The Mythical Man-Month for software teams in 1975. The number of communication channels in a connected system is N(N-1)/2. Brooks was talking about people on a project; the arithmetic applies identically to systems on a stack. Each new tool doesn't add one possible connection; it adds N-1 of them.
The 2025 Salesforce/MuleSoft Connectivity Benchmark — 1,050 IT leaders globally — found only 29% of business applications are connected on average. Not because companies don't want to connect them. Because integration needs grew faster than capacity, and teams gave up. Topology is what lets a small team manage 12 tools without giving up.
Every SMB eventually crosses a threshold where ad-hoc point-to-point stops working — usually around 6–8 tools. Below it, you remember what you wired. Above it, you can't. Migrating away from point-to-point sprawl takes 4–8x the effort of choosing hub-and-spoke at the start.
The 4 integration patterns explained
Academic catalogs name dozens of patterns (the Enterprise Integration Patterns book lists 65). For SMBs, four cover the decision space.
Pattern 1: Point-to-Point
Point-to-point integration is when every tool that needs another tool's data is wired directly to it — no middle layer. Shopify pushes orders straight to QuickBooks. HubSpot fires a webhook into Slack. Your form provider posts directly to your CRM. Each connection is its own piece of plumbing, configured separately, owned (in theory) by whoever set it up.
[Shopify] ──────► [QuickBooks]
│ │
▼ ▼
[HubSpot] ──────► [Mailchimp]
│ ▲
└────────────[Slack]How it works. Each pair gets its own connector — sometimes a native vendor integration, sometimes a one-off Zap, sometimes a webhook handler somebody wrote.
When it scales. Three or four tools, two or three active flows. Below that line, point-to-point is genuinely the right answer — the simplest thing that works.
When it breaks. Around 6–8 tools, the math turns on you. You stop being able to draw the diagram from memory. Connections get duplicated because nobody knows the existing one is there. When something breaks, it takes 90 minutes to figure out which connection broke. Documentation is the silent failure: in a point-to-point stack, nothing is documented at all, because no one is hired to think about the topology.
Complexity cost. Cheap to start, expensive to operate. Scales as N². The sprawl is invisible until it isn't.
Pattern 2: Hub-and-Spoke
Hub-and-spoke integration is when one central tool — almost always an iPaaS like Zapier, Make, or n8n — is the only thing each tool talks to. All connections route through the hub. Microsoft documents this pattern in the Azure Architecture Center; AWS describes the same shape in its networking reference patterns.
[HubSpot]
│
│
[Shopify] ── [iPaaS HUB] ── [QuickBooks]
│
│
[Slack] [Mailchimp] [ClickUp]How it works. Every tool sends data to (or receives from) the hub, never directly to another tool. The hub holds routing logic, mapping rules, retry behavior, and error handling. Adding a tool means building one new spoke — not N-1 connections.
When it scales. 5 to 30 tools. The sweet spot for the entire SMB market.
When it breaks. Two failure modes. The hub becomes a single point of failure — if your iPaaS is down, every connection is down. And high task volume hits per-task pricing painfully (Zapier becomes expensive past ~50,000 ops/month; covered in our iPaaS vs. custom integrations piece). Both bounded — the second is exactly the signal that you're ready for a different topology.
Complexity cost. Modest. The hub costs $20–$300/month. Each connection lives in one place, debuggable in one place, with one named owner. Linear scaling.
Pattern 3: Mesh (Event-Driven)
Mesh integration is when tools publish events to a shared bus, and any other tool subscribes to the events it cares about. No central router. Each tool is loosely coupled — it knows nothing about who consumes its events. This is the pub/sub pattern behind AWS EventBridge, Google Pub/Sub, and Kafka.
┌──────────────────┐
│ EVENT BUS │
└──────────────────┘
▲ ▲ ▲ ▲ ▲
│ │ │ │ │
publishes│ │ │ │ │subscribes
│ │ │ │ │
[Shopify] [Stripe] [HubSpot] [Slack] [Warehouse]How it works. Shopify emits an order.created event. The event hits the bus. Three subscribers — accounting, fulfillment, customer notification — consume it independently. Adding a fourth subscriber means subscribing to the existing event, not changing anything Shopify does.
When it scales. High volume (>100K events/month), real-time requirements, or workflows where many independent consumers react to the same event. E-commerce with thousands of orders a day. Logistics. Real-time fraud detection.
When it breaks. Mesh is unforgiving on operational discipline. You need event schemas managed centrally — or you get the field-drift problem from why integrations break, worse, because every consumer breaks at once. You need monitoring on every subscription, and someone who understands at-least-once vs. at-most-once delivery semantics. For most SMBs without an in-house engineer, mesh is overkill that masquerades as elegance.
Complexity cost. High. The platform is cheap (AWS EventBridge is nearly free at SMB scale); operational cost is real. Mesh is the right answer maybe 5% of the time — but when it's right, nothing else fits.
Pattern 4: ESB (Enterprise Service Bus)
An Enterprise Service Bus is a formal middleware layer that sits between every system, providing transformation, routing, governance, and orchestration as managed services. Think MuleSoft Anypoint, IBM Integration Bus, Boomi, or Workato Enterprise.
How it works. Conceptually similar to hub-and-spoke, but the hub is heavier. ESBs ship with full data-mapping languages, BPMN-style orchestration, governance dashboards, audit trails, and team workflows that assume an integration team exists.
When it scales. Past $50M revenue, regulated industries (healthcare, financial services, insurance), multi-entity operations with strict data-sovereignty rules.
When it breaks. When SMBs buy one. We've seen it twice in three years — both bought ESBs because a vendor told them they "should be on enterprise architecture." Both regretted it. Implementation took 14+ months. Annual cost was 20x hub-and-spoke. Neither filled more than 30% of the platform's capabilities.
Complexity cost. Enormous, by design. ESBs aren't built for businesses without a CIO. We name the pattern here only because the term shows up in vendor pitches — we want SMBs to recognize it and politely decline.
The 80% rule for SMBs
For roughly 80% of SMBs, hub-and-spoke is the right pattern and an iPaaS is the right hub. Four reasons:
- Linear scaling. Each new tool adds one spoke, not N-1 connections. A business growing from 8 to 14 tools triples raw connection capacity (28 to 91) but adds only 6 spokes. The hub absorbs the combinatorial explosion.
- Single source of audit truth. Every connection lives in one iPaaS dashboard. When something breaks, you look in one place. When you onboard a new ops lead, you point them at one tool. When you audit annually — per our year-2 piece — there's one inventory to walk.
- Named ownership becomes possible. Owner attrition is the biggest year-2 failure mode. Hub-and-spoke makes ownership tractable: one person owns the iPaaS account, flows get assigned within it, credentials live in one password manager entry. Point-to-point spreads ownership across vendor portals nobody can find.
- It fits the iPaaS market. Every SMB-tier iPaaS — Zapier, Make, n8n — is designed to be a hub. Compare head-to-head: Zapier vs. n8n, Make vs. n8n, or our automations directory for real workflow examples.
The takeaway: 5–25 tools, under 50K ops/month, workflows still in flux → hub-and-spoke on an iPaaS, full stop. The more interesting architecture is almost always the wrong one.
When SMBs need something other than hub-and-spoke
The 80% rule is not the 100% rule. Four specific scenarios genuinely call for a different pattern, and recognizing them early saves an expensive course-correction later.
Scenario 1: High event volume (>100,000 ops/month). E-commerce shops processing thousands of orders a day. Logistics ingesting GPS pings. Marketplaces emitting events on every transaction. Past 100K ops/month, hub-and-spoke iPaaS pricing turns punitive (Zapier alone can cross $500/month here) and single-hub latency starts to matter. The right answer is mesh on top of hub-and-spoke: events go to a bus (AWS EventBridge or n8n queue mode); the iPaaS handles lower-volume control flows.
Scenario 2: Regulated data with strict provenance requirements. Healthcare PHI, certain financial data, contractually-restricted client information. Hub-and-spoke through a third-party iPaaS may violate compliance even with a BAA. The right answer is usually custom + ESB-lite on owned infrastructure — self-hosted n8n on your own servers, custom code where the platform won't do. Workato or Boomi enter only if your compliance officer needs the certifications.
Scenario 3: Multi-region or multi-entity operations. A business with three regional subsidiaries, each running its own QuickBooks with local tax rules, plus a parent needing consolidated reporting. The right answer is federated hub-and-spoke — one hub per region, plus a parent hub that talks only to the regional hubs. Two layers, each still a clean hub-and-spoke.
Scenario 4: High-velocity startup with rapidly changing workflows. Some early-stage businesses change workflows monthly and need to rewire in days. The right answer is mesh-style with iPaaS — events emitted as source of truth, n8n or Make consuming what they need, low coupling so changes don't ripple. Common in pre-Series-A SaaS companies with 30+ tools.
If your business looks like one of these, name it explicitly. Architecture at month one is much harder to change at month thirty-six.
The N² scaling math, with the actual numbers
"Integrations scale as N²" is true and useless. The actual numbers are more honest.
| Tools (N) | Possible connections N(N-1)/2 |
|---|---|
| 3 | 3 |
| 5 | 10 |
| 8 | 28 |
| 10 | 45 |
| 12 | 66 |
| 15 | 105 |
| 20 | 190 |
You almost never want every tool connected to every other tool — most SMBs only build 30–50% of possible connections. But that's still the exposure surface — the connections you might have to debug or refuse.
The pain threshold is N=8. At 8 tools, you have 28 possible connections and roughly 10–14 active ones. Below it, point-to-point is survivable. Above it, the only sensible pattern is hub-and-spoke.
Most SMBs cross this line without realizing it — stack-purchase by stack-purchase, never as a single decision. Each purchase is rational; the cumulative architecture is accidental. Our Connected SMB Maturity Model Stage 2 "Tooled" is exactly the population that has crossed N=8 without choosing a pattern.
Choose at tool 6. Choosing hub-and-spoke too early costs you a slightly underutilized iPaaS subscription. Choosing it too late is an unwinding project that takes a quarter.
How to choose: the 4-question decision tree
The question sequence we use on Stack Audits, in under five minutes:
Q1: How many tools generate or consume integration-relevant data? Count anything holding customer, financial, or operational data. 4 or fewer → point-to-point is fine. 5–14 → iPaaS hub-and-spoke. 15+ → hybrid territory.
Q2: What's your monthly ops volume across all integrations? Below 50K → hub-and-spoke. 50K–200K → still hub-and-spoke, pricing matters. Above 200K → start thinking mesh or hybrid.
Q3: How often does the integration logic change? Monthly → hub-and-spoke or mesh-with-iPaaS, because changing custom code is too slow. Quarterly → hub-and-spoke. Yearly → any pattern works.
Q4: Hard compliance regime? HIPAA, PCI-DSS Level 1, GDPR residency, SOC 2 with strict customer contracts. Yes → self-hosted hub-and-spoke (n8n on your infra), custom, or enterprise iPaaS/ESB past a certain size. No → SMB-tier iPaaS handles it.
Shortest version: 5–25 tools, under 50K ops, no extreme compliance, workflows still in flux → hub-and-spoke on an iPaaS, full stop. Roughly 80% of the SMBs we see.
Migration path: from point-to-point sprawl to hub-and-spoke
Most SMBs reading this are migrating, not greenfielding. They have 8–14 tools, a tangle of accidental point-to-point connections, and a sense that "we should clean this up." The migration path that works:
- Inventory. Box-and-arrow audit from our systems integration guide (~30 minutes). Every tool is a box; every connection is an arrow labeled with what it does and who set it up. You'll find connections nobody remembers configuring. Normal.
- Pick the iPaaS that fits your size. Criteria in our iPaaS vs. custom integrations guide. For 5–50 employees, Zapier, Make, or n8n. Pick one and commit — the whole point of hub-and-spoke is one hub.
- Migrate the highest-value connection first. Usually accounting ↔ CRM. Build the hub-and-spoke version, run it in parallel with the old point-to-point for 14 days, then turn off the old one. Each connection gets a two-week soak.
- One connection per week, in priority order. A 10-tool SMB with 8–10 active integrations finishes in 8–10 weeks of part-time effort.
- Document and assign ownership. One paragraph per spoke: what it does, when it runs, what it touches, who owns it, what to check when it breaks. Without this, you've moved from sprawl to a different kind of sprawl.
- Quarterly audit. Walk the inventory every 90 days. Spokes still running? Credentials current? Vendor API changes? The 15-minute version is the difference between integrations that last 5 years and ones that decay at month 18.
If you want help running the migration — or just the box-and-arrows audit — we run a free 30-minute Stack Audit. Video call, no pitch. We tell you which pattern your stack is accidentally running, and what the migration looks like.
Frequently asked questions
What's the simplest integration architecture for a small business?
For most SMBs, the simplest architecture that actually scales is hub-and-spoke with a single iPaaS — Zapier, Make, or n8n — as the central hub. Every tool connects to the hub, never to another tool. It costs $20–$300/month, scales smoothly from 5 to 30 tools, and gives you one place to debug, audit, and assign ownership. Point-to-point is technically simpler (no platform), but it stops working past about 6–8 tools.
When should an SMB move from point-to-point to hub-and-spoke?
The threshold is around 6–8 tools or 5+ active data flows. Below that, point-to-point with a few well-chosen connections is fine. Above it, the N² math catches you. Migration takes 8–10 weeks of part-time effort for a 10-tool stack, runs in parallel with existing connections so nothing breaks, and pays back in lower maintenance cost almost immediately. Don't wait until you feel pain — by then, the migration is twice as expensive.
Do SMBs need an Enterprise Service Bus (ESB)?
Almost never. ESBs (MuleSoft Anypoint, IBM Integration Bus, Boomi, Workato Enterprise) are designed for organizations with 50+ systems, dedicated integration teams, and strict regulatory requirements. They cost 20x what hub-and-spoke iPaaS costs and require 14+ month implementations. Two cases where an SMB might genuinely need one: a regulated business approaching $50M+ revenue (healthcare, finance, insurance), or a multi-entity organization with strict data-sovereignty contracts. Outside those, the answer is hub-and-spoke.
How many integrations is too many for point-to-point?
Point-to-point breaks down at 6–8 tools, when possible connections cross 15–28 and active connections cross 8–10. Concretely: if you can't draw your stack's connection diagram from memory in under five minutes, you're past the line. The right move isn't to add a 9th connection on top of the tangle — it's to migrate the whole thing onto a single hub-and-spoke iPaaS.
About the author. Alejandro Morales is a senior operations consultant and systems architect at STOA Digital Solutions. STOA helps SMB owners ($500K–$20M revenue) choose the right software, connect it, automate routine work, and build operations that don't depend on the owner being in every meeting. Based in the Triangle, NC; serving the US.
Sources cited.
- Brooks, Frederick P. — The Mythical Man-Month, Addison-Wesley, 1975. Original communication-channels-grow-as-N² argument. https://en.wikipedia.org/wiki/TheMythicalMan-Month?utmsource=stoa-agency&utmmedium=referral&utm_campaign=integration-architecture-patterns
- Salesforce / MuleSoft — 2025 Connectivity Benchmark Report (1,050 IT leaders globally). Application-connectivity rates and integration cost data. https://www.salesforce.com/news/stories/connectivity-benchmark-report-2025/?utmsource=stoa-agency&utmmedium=referral&utm_campaign=integration-architecture-patterns
- Microsoft — Azure Architecture Center: Hub-Spoke Network Topology in Azure. Reference documentation. https://learn.microsoft.com/en-us/azure/architecture/networking/architecture/hub-spoke?utmsource=stoa-agency&utmmedium=referral&utm_campaign=integration-architecture-patterns
- Hohpe, Gregor and Woolf, Bobby — Enterprise Integration Patterns, Addison-Wesley, 2003. The 65-pattern catalog. https://www.enterpriseintegrationpatterns.com/?utmsource=stoa-agency&utmmedium=referral&utm_campaign=integration-architecture-patterns
- STOA Digital Solutions — operational observations from 100+ SMB Stack Audit engagements, 2024–2026.