Architectural Strategy: Decoupling a Point-to-Point Integration

Context and Scale

Twin v1 was our monolithic distributor system handling everything from sales to warehouse management and delivery. When the business split its operations into separate warehouse and delivery entities, our tech company saw an opportunity. We decided to build a multi-tenant SaaS Warehouse Management System (WMS) and Fleet Management System (FMS) as isolated "miniservices ."

The idea was to use our internal distributor as a test run—migrating operational flows out of Twin v1 and into these new SaaS products, while keeping Twin v1 as the core sales and finance point. To make this work, we needed seamless data synchronization across all three systems, handling hundreds of daily data points for an initial rollout of over 100 users.

Problem

Because the WMS and FMS were designed to eventually be sold as independent SaaS products, they were strictly encapsulated. To keep them synced with Twin v1, the initial integration was rushed: we relied heavily on direct Point-to-Point (P2P) API calls and webhooks .

This approach worked in theory, but in reality, it created a fragile, tangled chain of data. A flow wasn't just moving from A to B; it could jump from Sales to Warehouse, Warehouse to Delivery, and then back to Sales. If a network blip or logical error broke the chain at any point, the failure was silent. To find where the data was lost, we had to manually trace and cross-reference logs across three entirely separate applications. Debugging became a complex, time-consuming nightmare.

Constraints

I was fully aware that this architecture was unsustainable, especially if we planned to scale and sell this SaaS to external tenants. However, the system was already in production and supporting live daily operations. The business was simply not interested in halting development to spend time and effort reinitiating the integration flow.

As a compromise, we built a reconciliation scheduler to proactively scan all three databases for missing or inconsistent data. It was a band-aid, not a cure. It kept the daily error rate low enough for our initial users, but the architectural debt was still there.

Proposed Blueprint

To fix the root cause, I designed a blueprint for a Centralized Integration Service—a Hub-and-Spoke orchestrator. Instead of direct communication between each app, every system would communicate strictly with this central proxy.

This service would act as a single source of truth for the integration, handling centralized logging, queueing, and automated retry mechanisms. If an application went down or a request failed, the hub would gracefully hold the state rather than silently dropping the data. It was a clean, scalable way to decouple the systems.

Outcome

In the end, the new architecture was never built. The project was halted entirely because the internal distributor company went bankrupt. The application simply wasn't needed anymore.

However, the temporary reconciliation Loop solution did fulfill the immediate business requirements while the company was still running. More importantly, the engineering team fully agreed with my technical audit, and the Hub-and-Spoke blueprint was adopted as the standard for any future multi-system integrations.

Reflection

This experience taught me that rushing the early stages of integration—thinking "we just need to send data from A to B, let's just use an API"—quietly builds massive long-term costs. When building distributed systems, you cannot just look at what is directly in front of you.

Direct integrations without a clear, centralized strategy quickly turn into fragile webs. Today, I am much more intentional about thinking through the holistic architecture, observability, and failure states long before the first API contract is ever written.

Questions & Answers

Q.
Why a Hub-and-Spoke proxy instead of a "proper" event-driven architecture like `Kafka`?

Because we weren't building a unified internal platform; we were building standalone SaaS products. We chose a miniservice approach specifically so each app could be sold independently. If we had forced them to share a message broker, we would have permanently tethered their lifecycles together. A Hub-and-Spoke model allowed the WMS and FMS to stay "clean" and product-focused, while the Hub handled the messy, internal translation logic.

Q.
If you could redo this integration, would you choose the same Miniservice path?

In hindsight, I’ve realized that architecture must be right-sized to the team, not just the technology. While the miniservice approach was theoretically clean, it was too heavy for our small team to maintain effectively. We were paying a "Distributed Systems Tax "—the overhead of managing multiple deployments and complex data syncing—on top of our daily feature work. If I were starting again with that same team size, I would opt for a Modular Monolith . It would provide the same code boundaries and multi-tenant flexibility, but without the high operational cost of network calls and API webhooks. I’ve learned that a "clean" architecture is only successful if the team is large enough to support the infrastructure it requires.