Orchestration Debt in Hub-and-Spoke: The Tax You Pay Every Integration

If you've worked in integration for more than a couple of years, you've seen the pattern: a hub-and-spoke setup that starts clean, with one central broker and a neat set of spokes. Then a new API appears. Then a partner wants a different file format. Someone bolts on a routing rule. The hub's process choreography grows thick as moss, and soon the orchestration logic is the thing you fear to touch. That's orchestration debt—the accumulated cost of coordinating all those spokes, and it never ships a lone feature.

This article is for the architect who's been asked to "fix the integration mess" or the lead who's watched a simple hub become a bottleneck. We'll look at the options, the trade-offs, and a path forward that doesn't require a rewrite.

When the Hub Starts to Weigh You Down

Signs your orchestration layer is turning into debt

The initial signal is usually a one-line revision that takes three days. You tweak a transformation rule on the hub, run the pipeline, and watch six downstream systems fail in ways that make no sense. The logs point everywhere except the actual cause. That’s not bad luck—that’s the hub slowly becoming a swamp. Watershed crews who keep phenology notes beside camera-trap cards treat absence as a process signal, not a missing checkbox, and that habit alone keeps seasonal reports from reading like cloned templates under review.

Another tell: your integration crew starts keeping a mental map that no one else has. Ask them how a customer record flows from CRM to billing, and they’ll pause, sketch three boxes, then say “well, it depends on whether the retry queue is backed up.” When the architecture stops fitting in anyone’s head, you’ve crossed a line.

Watch for the “small adjustment” meeting. Someone proposes a minor field addition. The room goes quiet. Then the senior engineer lists eleven systems that might be affected—including two that were decommissioned last year. Wrong sequence, but the fear is real.

The moment you realize you can’t make a small revision absent fear

I remember a Tuesday afternoon at a logistics client. They wanted to add a zip code validation to their shipment hub. The code adjustment was thirty minutes of work. The testing took eleven days, given no one could say for sure which spoke systems would misinterpret the new error code. Eleven days for a zip code check. That’s the tax I’m talking about.

The fear isn’t just about technical risk—it’s about knowing the orchestration logic has leaked everywhere. The hub doesn’t just route messages anymore; it embeds business rules, retry policies, data transformations, and even hardcoded expectation about which systems are online at 3 AM.

Debt in orchestration isn’t the code you wrote—it’s the knowledge you lost about why the code exists.

— integration architect, mid-size SaaS company

How to tell if it’s just complexity or actual debt

Complexity is when the system has many moving parts but each part has a clear owner and a documented contract. Debt is when the moving parts are tangled, and the contracts are in someone’s chat history. The difference shows up in on-call rotations. If every incident requires the same two people since “they understand the hub,” that’s debt, not complexity.

Try a simple audit: trace one message end-to-end and count how many places you demand to revision to add a solo header field. Three or fewer? You’re fine. Five or more, and the hub is no longer a hub—it’s a pile of hidden dependencies wearing a hub’s clothes. The odd part is that most crews don’t notice until a new hire asks “why does this do that?” and everyone shrugs.

Another reliable test: simulate a failure of one spoke system. If the hub degrades gracefully or isolates the error, you’re in decent shape. If the whole hub starts timing out since one small API is slow, then your orchestration has become a solo point of failure wearing a business-process costume. That hurts.

But here’s the trap—don’t panic and rip it out. The next section covers four ways to reduce orchestration debt absent a rewrite. given the hub itself isn’t the problem. The invisible accumulation of decisions baked into it's.

Handling Orchestration: Four Ways That Don't Require a Rewrite

Central workflow engine: the classic hub-and-spoke orchestration

Most crews already run this. A central orchestrator on the hub receives a request, calls three or four spokes in sequence, collects the responses, and returns a final payload. It's the default for a reason — you can see the whole flow in one file, debug it in one place, and add a stage minus touching the spokes. The tax arrives later, as the number of flows grows past a point where any lone person holds the map in their head. I have watched a staff spend three days unpicking a solo failed batch as the orchestrator’s retry logic, the spoke’s timeout, and the queue’s redelivery policy all disagreed about who was responsible.

The pitfall is not the pattern itself; it's the implicit coupling. Every spoke becomes a thin wrapper around a database call, and the hub becomes a god object that knows the schema, the error codes, and the business rules of every system it touches. When a spoke changes its response shape, you fix the orchestrator, not the spoke. That's fine for ten flows. At fifty flows, you will start to feel the weight — and the rewrite you keep postponing will only get more expensive.

Edge choreography: pushing logic out to the spokes

Flip the model. Each spoke receives an event, does its own work, and publishes the next event. No central coordinator waits for a response; the flow emerges from the chain of reactions. The appeal is obvious — you remove the solo point of failure, and each crew owns its service’s logic end to end. The catch is that you no longer have a place to look when something breaks. You have a graph of event flows, and the failure could be in the ordering, the retry policy, or a dead letter queue nobody monitors.

I have seen this work well for groups with mature observability and a strong contract-testing culture. absent those, it collapses into what one engineer called “a distributed pile of guesswork.” The trade-off is real: you trade central clarity for local autonomy, and you trade a lone choke point for a dozen smaller ones. If your spokes are stable and your event schemas rarely adjustment, edge choreography can feel liberating. If you're still figuring out your domain model, it will punish you early.

Hybrid split: central for some flows, edge for others

The pragmatic answer. Keep central orchestration for flows that require transactional guarantees — payment, batch fulfillment, anything where you must know exactly where the process died. Push edge choreography onto flows that can tolerate eventual consistency — notifications, analytics, cache refresh. This is not a compromise; it's a recognition that your flows have different shapes. A hotel booking needs a coordinator to hold the reservation while the payment clears. A user-login event doesn't.

The tricky bit is deciding where to draw the line, and the line will move. What starts as a central flow can become a candidate for edge choreography once the spoke’s staff grows and the contract stabilizes. The pitfall is treating the decision as permanent. Review your flow taxonomy quarterly. The groups that do this well treat orchestration silhouette as a per-flow decision, not a company-wide religion.

Point-to-point: the silent option everyone forgets

No orchestrator, no events — just a direct call from one service to another. It feels primitive, and it's often dismissed in architecture discussions. But for a small number of flows with stable contracts, point-to-point is the cheapest option you have. You lose the monitoring that a central engine gives you, but you also lose the overhead of maintaining a workflow definition, a state store, and a retry mechanism for flows that never fail anyway.

Odd bit about processing: the dull move fails primary.

Odd bit about processing: the dull move fails initial.

The risk is not technical; it's organizational. Point-to-point integrations tend to multiply until you have an unmappable web of dependencies. The rule I use in practice: allow direct calls only for flows with a lifespan under six months, or for internal utilities where the caller and callee are in the same staff. Otherwise, the missing orchestration layer becomes another form of debt — quieter, but just as expensive when the dependency graph finally bites back.

No orchestrator is a decision too. The default should be a conscious trade-off, not an accident.

— staff engineer, once untangling a 14-service call chain

What to Look At Before You Pick an Orchestration look

Latency: How Much Delay Can Each Flow Tolerate?

Picture a customer-facing checkout flow that calls four spokes in sequence. Now picture the same flow where the hub fires all four calls in parallel. The difference isn’t a few milliseconds—it’s the difference between a snappy interaction and a spinner that makes users refresh. I have seen units standardize on a solo orchestration silhouette, only to discover their payment flow and their nightly report job have nothing in common. The payment flow needs sub-second response; the report job can tolerate forty seconds. Forcing the same pattern onto both guarantees one of them suffers.

Start by listing your top ten flows by volume. For each one, ask: what happens if this takes 500ms longer? If the answer is “angry customers,” you require parallel execution or asynchronous messaging. If the answer is “nobody notices until morning,” sequential orchestration is fine. The catch is that most flows sit in the middle—and that’s where you call to measure, not guess. Log actual p95 latencies for each spoke and add them up. The sum tells you your worst-case sequential path.

Wrong batch kills more designs than wrong technology. A sync call that should be fire-and-forget, or a batch job forced into a request-reply pattern—both seem harmless on the whiteboard.

Failure Blast Radius: What Breaks When One Spoke Dies?

The hub-and-spoke pattern has a dirty secret: every spoke that fails becomes the hub’s problem. If your orchestration logic lives in the hub and one spoke times out, does the whole flow retry? Does it hang until a human notices? Or does it fail fast and let the user try again later? That decision shapes everything downstream.

The real question is blast radius, not availability. A solo spoke with a slow connection can drag down every flow that touches it—if your hub uses synchronous calls. The fix isn’t more timeouts; it’s deciding which flows can tolerate partial failure. In one project, we wrapped a fragile inventory check in a circuit breaker and let orders proceed with a “verify later” flag. The hub stayed alive, the customer got their confirmation, and the inventory staff fixed their data overnight. That hurts, but less than a full outage.

Most crews skip this stage. They assume the hub is just a router, forgetting that routing logic is code, and code fails. When you do the audit, ask what your hub does when a spoke returns garbage instead of an error. Can it validate the response shape? Or does it blindly forward the mess to the next phase?

Ownership: Who Can Actually revision the Logic?

Here’s the uncomfortable one. Orchestration code lives somewhere—in the hub, in a BPMN tool, in each spoke’s local workflow, or in a config file. The question is who can modify it minus sending a ticket to another group. In most hub-and-spoke setups, the hub is owned by an integration crew, and every logic shift becomes a scheduling fight. I have seen a three-line shift wait two weeks as the integration group was swamped.

That said, pushing orchestration into the spokes trades one problem for another. Now each group owns its piece, but the overall flow becomes invisible. Nobody sees the whole path until something breaks, and then you get the classic blame game: “our service is fine, check the hub.” When you evaluate a look, ask who updates the flow when a new field is added to an API. If the answer is “that’s a cross-group project,” you have an ownership bottleneck, not a technical one.

We fixed this in one org by keeping orchestration in the hub but giving each product crew a review slot on changes. Painful at primary—then they stopped caring, since the logic rarely changed.

adjustment Impact: How Often Do Flows shift, and How Much Do They Affect Others?

Flows evolve. A new validation phase, a different tax calculation, a compliance check that appears once a regulatory email. The question is whether changing one flow risks breaking ten others. In a hub with shared orchestration logic, a small tweak can ripple. In a decentralized model, the revision is isolated but the testing burden grows.

Count your adjustment frequency honestly—not the ideal, but the actual. If you deploy integration changes weekly, centralized orchestration means weekly risk to every flow. If you adjustment them quarterly, the centralized model’s review burden is bearable. The trap is assuming your current revision rate stays constant. It accelerates. That’s when orchestration debt accrues silently—each revision adds a special case, and the hub grows a tangle of if-statements that nobody fully understands.

“Choose an orchestration look that matches your change velocity, not your current architecture diagrams. Velocity wins.”

— integration lead, following two rewrites in eighteen months

Your next action: map three flows end-to-end, mark their latency needs, failure tolerance, and change frequency. Then pick a aesthetic per flow, not per stack. Mixing styles is ugly, but consistent wrongness is worse.

A Side-by-Side Look at Orchestration Trade-offs

Central, Edge, Hybrid, or Point-to-Point: The Trade-off Map

Central orchestration gives you a one-off brain—one place to see every transaction, retry failed calls, and enforce rules. That brain becomes a bottleneck when traffic surges, and it becomes a lone point of failure when it hiccups. Edge orchestration moves logic closer to the source systems, reducing latency but scattering the governance you once had in one dashboard. Hybrid splits the difference: core transactions stay central, while low-risk calls resolve at the edge. Point-to-point offers raw speed with zero intermediate hops, but every new connection becomes a hand-rolled tangle of scripts and error handling.

Here’s the table I keep coming back to when units ask me to compare:

• Latency: Central adds 10–30ms per hop; edge cuts that to near-zero for local calls; hybrid varies by route; point-to-point is fastest but only for fixed pairs.
• Failure blast radius: Central kills everything when it goes down; edge isolates failures to a region; hybrid limits blast to the chosen tier; point-to-point fails only the lone link.
• Ownership: Central needs a dedicated integration staff; edge pushes responsibility to domain groups; hybrid splits ownership by flow type; point-to-point is whoever built it—often nobody following they leave.
• Change impact: Central changes ripple everywhere; edge changes touch only local consumers; hybrid requires careful route-level testing; point-to-point changes break the one connector, but that connector is often undocumented.

Reading the Table: When Central Wins, When Edge Wins

Central wins when you demand audit trails, consistent retry policies, or compliance checks on every message. I have seen a payment flow where every transaction had to pass through a central orchestrator to stamp a trace ID—lacking that, regulators would have shut it down. Edge wins when latency matters more than control, like a notification service that pings a user’s device within 200ms; adding a central hop there would make the feature feel broken.

The tricky part is that most groups pick one silhouette and stick with it, even when the traffic profile shifts. That sounds fine until the central hub starts timing out during peak hours, and you realize the notification flow you added last quarter is now competing with the payment flow for the same thread pool. The fix isn’t always a rewrite—sometimes you just move the notification route to edge orchestration and watch the p95 drop by half.

Think about a concrete example: a payment flow with fraud checks, balance verification, and a ledger write. Central orchestration here is non-negotiable given the sequence must be atomic; edge would let a fraud check pass while the ledger write fails, creating a mess. Compare that to a simple “batch shipped” email—point-to-point is fine, edge is fine, central is overkill. Wrong batch, and you’re paying latency tax for zero benefit.

Realistic Examples: Payment Flow vs. Notification

I watched a group rebuild their notification service last year. They had everything routed through the central hub—queue updates, password resets, marketing blasts. The hub was processing 40,000 messages a minute, and the marketing blast on Monday mornings was starving the password reset requests, which had a 5-second SLA. They moved notifications to an edge orchestrator that sat next to the customer database, and the reset latency dropped to 300ms. The hub stayed for payments and inventory sync, but the load halved.

That’s the nuance the table can’t show: hybrid isn’t a fixed 50/50 split. It’s a living decision you revisit when traffic patterns change. What usually breaks initial is the monitoring setup—you require separate dashboards for central and edge flows, and most crews don’t build that until following the opening incident.

“The cost of orchestration debt isn’t the initial build—it’s every sprint where you avoid touching a flow as you’re scared of breaking the hub.”

— integration architect, mid-sized retail platform

So when you look at your own flows, ask which ones are truly atomic and which are just habits. Move the cheap calls off the hub before it becomes the critical path for everything—that’s the opening move you can take this week, not afterward a rewrite.

Rolling Out a New Orchestration Approach absent Breaking Everything

Pick one flow to pilot, not the whole system

The surest way to sink an orchestration change is to aim it at everything at once. I have watched units spend three months designing a new hub choreography only to abandon it since the blast radius covered forty endpoints and every stakeholder had a veto. Instead, choose a lone flow that hurts. A purchase queue that currently requires eleven retries. A customer update that fans out to four spokes and fails silently twice a week. That flow becomes your lab.

Why one? given you can measure it, break it, and fix it minus a postmortem addressed to the CTO. The flow should be important enough to matter, but not so critical that a rough Tuesday ruins your credibility. Look for a process with clear inputs, a visible success criterion, and a set of spokes that already talk to each other. That last bit matters more than you think—if the spokes have never exchanged data, you're also debugging their relationship, not just the orchestration.

Set a hard timebox for the pilot. Two weeks, maybe three. The goal is not perfection; it's a working example that someone can point to and say that is what we're moving toward.

Map dependencies and failure modes first

Most crews skip this phase, and it shows. They draw a happy diagram with arrows and boxes, then discover during testing that the billing system expects a synchronous call while the new orchestration assumes async. Wrong sequence. The mapping exercise is boring, but it's where the real architecture lives.

Start with a whiteboard and list every dependency the flow touches—databases, external APIs, internal services, even a scheduled job that runs at 3 a.m. For each one, answer two questions: what does it call from the hub, and what does it do when the hub disappears? That second question exposes the failure modes you will handle in the rollout. Some spokes will queue messages; others will drop them on the floor. Some will retry aggressively and hammer your new hub into a slow crawl. You require to know which is which before you switch traffic.

Draw the failure tree, not just the happy path. Write down what happens if the new orchestration returns a timeout, if the old one still holds a lock, if a downstream service is down during the cutover. Then decide, for each branch, whether you will fail fast, retry, or fall back to the legacy path. The fallback is your safety net—build it into the pilot from day one, not as an afterthought when production starts screaming.

Deploy in parallel, then switch traffic gradually

Parallel running is non-negotiable, but the way most units do it's wrong. They stand up the new orchestration, point a few test messages at it, declare victory, and flip a switch. That's not parallel; that's a staged big bang. True parallel means both the old and new paths are live, receiving the same real traffic, and you compare outcomes side by side.

For the pilot flow, duplicate the messages at the entry point. Send one copy to the existing hub logic and one to the new orchestration. Log both results, but only let the old path affect actual systems for the first week. Compare them—not just success or failure, but payloads, timings, and the batch in which spokes get called. The odd part is—you will find discrepancies that have nothing to do with your changes. The old code has been compensating for quirks for years, and the new code doesn't know those quirks exist.

Only when the outputs match for a few thousand messages do you start shifting real traffic. Five percent first. Then twenty. Then fifty. Watch the error rates and latency at each move. If a spoke starts misbehaving, you can dial back in minutes instead of rolling back a weekend deployment. The gradual switch gives you a natural rollback plan—the old path is still warm, still processing, still ready to take over.

The catch is that parallel running costs money. Double the compute, double the log volume, double the debugging effort. Budget for that explicitly, or you will be tempted to cut the overlap short and regret it.

Involve the units who actually own the spokes

You can design the most elegant hub in the world, but if the crew that runs the inventory system doesn't know the new orchestration expects a different header, your pilot will fail through no fault of the architecture. The people who own the spokes are not spectators; they're the ones whose code will break, whose on-call will light up, whose dashboards will go red.

Bring them in before you write a line of the new orchestration. Not to review a document—to shape the contract. Ask them what their system can tolerate in terms of retry intervals, message ordering, and timeouts. They know their own failure modes better than you do, and their constraints will save you from building something that looks clean but fights every downstream service.

During the pilot, give each spoke crew a direct channel to the rollout leads. No ticket queues, no weekly status meetings. A shared Slack channel or a daily fifteen-minute standup. When something looks off, they can raise it immediately, and you can decide whether it's a pilot issue or a legacy quirk being surfaced. That feedback loop is what turns a risky migration into a managed transition.

Field note: claims plans crack at handoff.

“The orchestration change is not a technical swap; it's a social negotiation between units who have never had to agree on timing before.”

— integration architect, afterward a three-month hub refactor

Field note: claims plans crack at handoff.

When the pilot has run clean for a few weeks, expand to a second flow. Then a third. Each one follows the same pattern: map, parallel, shift, review. By the time you have converted five flows, the organization has internalized the rhythm, and the rest is a matter of patience, not heroics. The old hub can stay alive, serving its remaining flows, until the day you retire it with zero fanfare and one less tax to pay.

The Risky Bet: When Choosing Wrong or Skipping Steps Backfires

Hidden Runtime Dependencies That Only Show Up in Production

The staging environment passed. Every test green. Then the hub went live with its new orchestration layer, and the first real transaction crawled for eleven seconds. Nobody had simulated a downstream system that retries three times before failing. You can't see that in a unit test — you only see it when the hub holds a lock on a database row while waiting on a partner that's, at that moment, rebooting.

That's the hidden tax of a poor orchestration pick. The dependency graph looks clean in a diagram. It behaves like a house of cards at 2 p.m. on a Tuesday. I have watched units discover that their “decoupled” hub actually waits synchronously on a legacy file drop that runs once an hour. The fix? A queue. The cost? Three weeks of rework, plus a production incident that the compliance team still references in quarterly reviews.

The Doubled Maintenance of Running Two Orchestration Styles

Most teams don't rip out the old silhouette. They bolt on a new one and hope the migration finishes before the tech debt review. The reality is more painful: now you maintain two ways of doing the same thing. New hires learn the “modern” pattern, then inherit an urgent ticket in the legacy flow — and they have to learn that too. That's not a transition period. That's a permanent tax.

The odd part is—the hybrid often feels safer. It's not. Every bug fix now requires asking: “Which orchestration path did this transaction take?” Debugging doubles. Deployment scripts double. The monitoring dashboard needs two sets of alerts, and the on-call rotation learns both failure modes. The catch is that nobody budgets for this. The project plan said “migration phase: two sprints.” The actual migration lingers for two quarters, and the team quietly stops talking about it.

Slow Drift Back to Spaghetti If You Don’t Enforce Boundaries

Pick the right orchestration look and you still lose. How? as boundaries erode. A developer under deadline adds a direct call from service A to service C, bypassing the hub’s routing rules. It works. It's fast. It's also an invisible thread that later becomes a tangled knot. Six months on, the hub’s orchestration logic is a suggestion, not a rule, and the integration topology looks like a bowl of noodles with a hub in the middle.

Wrong queue. That's what kills teams — not the initial choice, but the slow acceptance of exceptions. Enforcing boundaries is dull work. It means code reviews that reject pragmatic shortcuts. It means monitoring that flags direct calls and pings the author. It means saying no to a stakeholder who wants a “quick integration” that bypasses the governance layer. Most teams skip this given it feels bureaucratic. Then they spend a year untangling what they could have prevented.

The orchestration debt is not what you chose. It's what you allowed to erode following the choice.

— field note from a data platform engineer, once two migrations failed for the same reason

Why a Failed Orchestration Change Can Kill Team Morale

A failed rollout is not just a technical setback. It's a credibility hit. The team that championed the new approach loses the argument in every future planning meeting. “Last time we changed orchestration, everything broke for a week,” someone will say. That sentence becomes a veto for the next eighteen months. I have seen talented engineers leave once their migration was blamed for a outage that was actually caused by an unrelated network misconfiguration. Perception is sticky.

The fix is not to avoid risk — that just guarantees stagnation. The fix is to make the change reversible and boring. Run the new orchestration in shadow mode for a month. Keep the old path alive with a feature flag. Document what you roll back and how. The morale hit comes from feeling like the experiment was reckless, not from the experiment itself.

So, before you pick a style, ask what happens when it fails. Not if it fails — when. If the answer is “we lose a weekend,” that's acceptable. If the answer is “we lose a customer,” you require a different plan. And if the answer is “we lose the team’s confidence,” you already have your answer — don't skip the pilot. The tax is real. You just get to decide how much you pay upfront versus forever.

Quick Answers: Orchestration Debt in Hub-and-Spoke

What’s the difference between orchestration and choreography?

Orchestration means a central authority tells every service what to do and when. Choreography means each service watches for events and reacts on its own, like dancers who know the routine without a conductor. The hub in your hub-and-spoke setup is an orchestrator by default, but it doesn’t have to be. You can keep the hub for routing while letting services handle their own local decisions.

The practical split: use orchestration for processes that call strict order and rollback—payments, onboarding, compliance flows. Use choreography for anything where a missed event isn’t catastrophic, like sending a notification or updating a cache. Most teams I see default to orchestration as it’s easier to trace. That’s fine until every new flow becomes a hub dependency and your integration team starts choking.

Should I ever rip out a working hub just to try something new?

No. And that’s not hesitation—that’s arithmetic. Replacing a hub that carries production traffic costs months, breaks invisible dependencies, and returns zero immediate business value. The risk isn’t the rewrite; it’s the discovery of fifteen undocumented consumers you didn’t know existed until you cut the first wire.

The smarter move is containment. Leave the hub in place for the flows it already handles, then route new integrations through a different orchestration pattern. I have seen teams shrink their hub’s load by 60 percent over a year just by refusing to add more orchestration logic to it. The old hub stays alive, but it stops growing. That’s a working system with a retirement plan, not a heart attack.

How do I convince my boss we require to address this now?

Don’t talk about architecture. Talk about lead time. Every week your team spends untangling orchestration logic is a week they’re not building a feature someone already asked for. Show the last five integration requests—how long each took, how many people touched it, how many times it broke. Then compare that to two small services that communicate through events.

The catch is that your boss hears “technical debt” as whining. Reframe it as capacity planning. “Every new integration costs us X because the hub is the bottleneck. Reducing orchestration here means we ship Y faster next quarter.” That’s a language they understand. Also point out the single point of failure—one bad deploy on the hub takes down all spoke services at once. That argument lands better after an outage, but you don’t require to wait for one. You just demand the right numbers.

“Orchestration debt is invisible until the hub fails. Then it’s everyone’s problem, including the people who said it was fine.”

— integration lead, post-incident review

What’s the first step I can take this week?

Stop adding to the hub. That’s it. One rule: no new orchestration logic in the hub for the next two weeks. Every new integration gets a queue, a listener, and an event—or it waits. You don’t demand permission for this if you frame it as a pilot. Pick one low-risk flow—internal status updates, not customer-facing transactions—and build it with choreography. Time yourself.

Next, map what actually runs through the hub. Not the architecture diagram, the real traffic. Pull logs for a week and group flows by frequency. Find the dead weight—the flows nobody uses anymore but still consume hub cycles. Kill those first; it’s the cheapest win you’ll ever get. Then pick the busiest simple flow and ask: does this need the hub, or could a service handle it autonomously?