The API-First Architecture Pattern That Saved Our Client S$2M

When Meridian Logistics came to us, they had 12 warehouse management systems across their Singapore and regional operations, none of which talked to each other. Orders had to be manually reconciled between systems daily. Staff in the Tuas facility were re-entering data from the JB hub into the Singapore system every morning.

The obvious answer was a big-bang rewrite: build a single unified platform, migrate all 12 systems, go live in 18 months. Two previous vendors had proposed exactly this. Both engagements had failed. We took a different approach.

Why Big-Bang Rewrites Fail for Logistics Companies

The failure mode for big-bang rewrites in logistics is predictable: the business keeps changing faster than the system can be rebuilt. New warehouse configurations, new carrier integrations, regulatory changes, M&A activity. By the time you finish rebuilding the old system, you have been building the wrong thing for 12 months.

For Meridian specifically, there was an additional constraint: the 12 legacy systems were from 8 different vendors, several of whom were no longer operating. Source code was not available for three of them. A full rewrite would have required reverse-engineering undocumented business logic from systems that had evolved over 15 years.

The API-First Strangler Fig Pattern

Instead of replacing the systems, we wrapped them. The strangler fig pattern involves building a new API layer around existing systems, gradually migrating business logic to the new layer, and eventually retiring the legacy systems when the new layer is complete. For Meridian, the implementation had four phases.

Phase 1: API Gateway and Event Bus.

We deployed a lightweight API gateway and event streaming layer on AWS MSK that could receive events from any system and route them to any other. This took 6 weeks and required no changes to the legacy systems.

Phase 2: Adapter Services.

For each of the 12 legacy systems, we built a thin adapter service responsible for consuming events from the event bus and translating them into the format each legacy system expected, and polling each legacy system for state changes and publishing them to the event bus.

Phase 3: Canonical Data Model.

With all systems producing events, we built a canonical data model: a single source of truth for inventory, orders, and shipments. This model was populated from all 12 systems and became the authoritative record for reporting, analytics, and cross-system workflows.

Phase 4: Business Logic Migration.

With a working integration layer in place, we began migrating business logic starting with the most painful manual reconciliation processes into purpose-built services that used the canonical model.

The Numbers

The initial investment was S$340,000 over 14 months, significantly less than the S$2.3M quote from the full-rewrite vendor. The measurable outcomes in the first year after go-live:

When to Use This Pattern

The API-first strangler fig works best when legacy systems contain valuable business logic that is expensive to reverse-engineer, the business cannot afford a full cutover period, systems are from multiple vendors with different data models, and the organisation wants to retire systems incrementally.

For most established Singapore businesses with five-plus year-old enterprise systems, some form of this pattern is almost always the right starting point.