You started with a simple integration. Your CRM talks to your billing system. One API call, one webhook, done in a weekend.
Then marketing needed the CRM data in their email tool. Sales needed billing data in their dashboard. Operations needed everything in their reporting system. Now you have 15 point-to-point integrations, three of them are broken, and nobody remembers who built the one connecting Stripe to your internal database.
This is the integration spaghetti problem. And it hits every growing company between 50 and 500 employees.
The Point-to-Point Trap
Point-to-point integration is the natural starting point. System A needs data from System B, so you build a direct connection. It's fast, it works, and it solves the immediate problem.
The math is what kills you. With 5 systems, you have up to 10 possible connections. With 10 systems, that's 45. With 20 systems — typical for a 200-person company — you're looking at 190 potential integrations.
Each integration has its own authentication, error handling, retry logic, and data mapping. Each one breaks independently. When Salesforce changes their API version, three integrations fail. When your billing system's webhook format changes, two dashboards go dark.
The real cost isn't building integrations — it's maintaining them. A MuleSoft survey found that enterprises spend an average of $3.6M annually on integration maintenance — more than they spent building the integrations in the first place. For mid-market companies, that number is lower in absolute terms but proportionally higher: 15-25% of the total IT budget goes to keeping systems talking to each other.
Three Patterns That Actually Work
1. The Hub-and-Spoke Pattern
Instead of connecting every system to every other system, route all data through a central hub. Think of it like an airport — instead of direct flights between every city, everyone connects through a hub.
How it works: Each system integrates once with the hub. The hub handles data transformation, routing, and delivery. When marketing needs CRM data, they don't connect to the CRM — they connect to the hub, which already has it.
Best for: Companies with 5-15 systems that need to share data. The hub reduces your integration count from O(n²) to O(n). With 10 systems, that's 10 integrations instead of 45.
Watch out for: The hub becomes a single point of failure. If it goes down, everything stops. You need redundancy, monitoring, and operational dashboards that alert before things break.
Implementation options: Managed iPaaS (Workato, Tray.io, Make) for non-technical teams. Self-hosted message broker (RabbitMQ, Redis Streams) for engineering teams that want control. Cloud-native (AWS EventBridge, Google Pub/Sub) for teams already deep in a cloud provider.
2. The Event-Driven Pattern
Instead of systems asking each other for data (polling), systems announce events and other systems listen.
How it works: When a customer is created in your CRM, the CRM publishes a "customer.created" event. Your billing system, email tool, and analytics platform all subscribe to that event and react independently. Nobody needs to know about anyone else.
Best for: Companies where data changes frequently and multiple systems need to react. E-commerce, SaaS, and any business where a single action (new order, new customer, status change) triggers work across multiple systems.
The key advantage: loose coupling. When you add a new system, you just subscribe it to the events it cares about. No existing integrations change. This is how companies go from manual processes to automated workflows without rebuilding everything.
Watch out for: Event ordering and idempotency. If "order.paid" arrives before "order.created" in one of your systems, things break. Design every consumer to handle out-of-order events and duplicate deliveries.
3. The API Gateway Pattern
A single entry point that manages authentication, rate limiting, versioning, and routing for all your APIs.
How it works: External partners, internal services, and third-party tools all hit the gateway. The gateway handles auth, transforms requests, applies rate limits, and routes to the right backend service. Your internal services never talk to the outside world directly.
Best for: Companies that expose APIs to partners, have multiple internal microservices, or need to manage access control across many consumers. Also essential if you're building custom software that other systems need to integrate with.
Watch out for: Over-engineering. If you have 3 internal services and no external partners, you don't need Kong or AWS API Gateway. A simple reverse proxy with auth middleware is enough. Scale the solution to the problem.
Choosing the Right Pattern
Your situation determines your pattern. There's no universal best answer.
</div>
If you have 5-10 systems that need to share master data (customers, products, orders) and changes happen a few times per day, the hub-and-spoke is your best bet. It's the simplest to reason about and manage.
If you have high-frequency events — orders, transactions, user actions — that need to fan out to multiple consumers in real time, go event-driven. The upfront investment is higher but the long-term flexibility is worth it.
If you're exposing APIs externally or managing a microservices architecture internally, the API gateway is essential. But it's a layer on top of one of the other patterns, not a replacement.
Most mid-market companies end up with a combination. Hub-and-spoke for master data synchronization, event-driven for real-time workflows, and a gateway if they have external integrations. The key is being deliberate about which pattern serves which use case — not letting it evolve accidentally into spaghetti again.
The Migration Path
You can't rearchitect everything at once. Here's the pragmatic approach.
Month 1-2: Inventory and prioritize. Map every integration you have. For each one, document: what data flows, how often, what breaks when it fails, and who maintains it. Rank by business impact. The integration that breaks your billing or customer onboarding is P0. The one that syncs a rarely-used dashboard is P3.
Month 3-4: Build the foundation. Set up your chosen pattern for the top 2-3 integrations. If you're going hub-and-spoke, stand up the hub and migrate your highest-value data flows. Don't migrate everything — start with the integrations that break most often or cause the most pain.
Month 5-8: Migrate incrementally. Move integrations to the new pattern one at a time. Run the old and new in parallel for 2 weeks before cutting over. This catches data mismatches before they become production problems.
Month 9-12: Decommission and document. Shut down old point-to-point connections. Document every integration in the new architecture: what it does, what data it moves, how to monitor it, and who owns it. This documentation is the difference between technical debt that compounds and an architecture that stays maintainable.
What This Costs
Realistic budgets for a 200-person company:
Managed iPaaS (Workato, Make): $24K-$60K/year in platform fees, plus 2-4 weeks of setup per major integration. Good if your team isn't heavy on engineering. Bad if you need custom logic or high-volume event processing.
Self-hosted (RabbitMQ, Kafka, custom middleware): $0-$5K/year in infrastructure, but 3-6 months of senior engineering time to build properly. Good if you have the engineering talent and want full control. Bad if you need results in 30 days.
Cloud-native (AWS EventBridge + Lambda, GCP Pub/Sub + Cloud Functions): $2K-$15K/year at typical mid-market volumes, plus 1-3 months of setup. Good balance of control and speed. Bad if you're not already on that cloud provider.
In all cases, the ongoing cost is lower than what you're spending on integration maintenance today — if you do it right. The "if" matters. A poorly executed migration creates new technical debt on top of the old.
Signs You Need to Act Now
Your engineering team spends more than 20% of their time on integration maintenance instead of building features. You've had a customer-facing outage caused by an integration failure in the last 6 months. You can't add a new tool without a multi-week integration project. Nobody on the team can explain all your current integrations end to end.
If two or more of these are true, your integration architecture is already limiting your growth. The longer you wait, the more expensive the migration becomes — and the more business risk you carry from software you've outgrown.
Build Integrations That Grow With You
Your systems should accelerate your business, not hold it back. If your integration architecture is fragile, expensive to maintain, or blocking new capabilities, it's time to rethink the approach. We help companies design and build integration architectures that handle today's complexity and tomorrow's growth. Book a discovery call to discuss your integration challenges.
