The migration challenge
A live API is a contract. Partners had integrated against the existing service - a legacy VB.NET/SOAP application - and any breaking change risked interrupting the flow of data they relied on. The rebuild therefore had two goals that usually pull in opposite directions: modernise the platform completely, and change nothing that existing consumers could see.
A modern serverless API
We built the new API on Amazon API Gateway's HTTP API, with each endpoint served by its own single-purpose AWS Lambda function. A single-table Amazon DynamoDB design holds the service's own domain - partners, brands and access rules - alongside a fast cache of the package data itself, for predictable low-latency reads at any scale. Access is gated per partner with API keys, and a purpose-built admin interface lets the team manage partners and configuration directly.
- Modern JSON/HTTP interface for new integrations, defined by a clear API specification.
- Serverless throughout - no servers to run, and cost scales with actual usage.
- Single-table DynamoDB for consistent, low-latency reads under variable load.
- Per-partner API keys for secure, controlled, multi-tenant access.
Zero-downtime migration
The key to a seamless cutover was backward compatibility. Alongside the modern JSON interface, the new service exposes a compatibility layer that speaks the same SOAP/XML protocol as the legacy API - serving the same contract, operation for operation. Existing consumers continued to call the service exactly as before, unaware that everything behind the interface had been rebuilt, while new integrations could adopt the modern interface at their own pace.
To give everyone confidence in the switch, we built a harness that fired identical queries at the old service and the new one in parallel and put their responses side by side - confirming the rebuilt API returned equivalent results before anything was moved across.
Cost-optimised by design
Because serverless bills per request, efficiency is a design concern rather than an afterthought. Two ideas do most of the work. First, the service resolves its filtering rules before it fans out to the data store: any request combination that a rule excludes outright never triggers a function invocation at all, and the rest are refined afterwards. Second, each request carries a response-time budget - the service fans a query out across every relevant combination and returns whatever has resolved within that budget, so it honours a real latency target rather than waiting on the slowest shard. The effect is a service that is both faster to respond and cheaper to run.
Key AWS services
- Amazon API Gateway (HTTP API): the modern, low-overhead front door to the service.
- AWS Lambda: a dedicated serverless function behind each endpoint.
- Amazon DynamoDB: a single-table design for fast, scalable data access.
- Amazon S3: storage for the admin interface's assets and supporting files.
