£1.2M in annual infrastructure cost optimisation from an API and Kafka estate rebuilt around real usage.
A digital-assets platform had built a universal API and a native API for each of its EVM and UTXO chains, plus a sprawling set of Kafka topics behind them: overlapping surfaces doing much of the same job. Nobody had a clear picture of what customers actually used. We found out, cut what wasn’t needed across the APIs and the Kafka estate, and rebuilt around a UTXO API and an EVM API, each driven by config to add additional protocols, with custom opt-in methods, moving every customer over without them noticing.
£1.2M
Annual infrastructure cost optimisation
EVM + UTXO
A dedicated API per chain type, extensible by config
Custom methods
Customers choose exactly the methods they need
0
Customer service interruptions during cutover
The challenge
EVM and UTXO, no shared design.
The client operated infrastructure spanning both EVM-compatible chains and UTXO-based chains. Over time they had built a universal API and a native API for each chain family, each maintained, documented and secured separately.
Nobody had a reliable picture of which endpoints and data fields customers were actually using across the estate. Some looked critical but were barely called. Others looked minor but sat behind live customer integrations. Endpoints and schema objects on the universal and native side of each chain family often returned materially the same data through different paths, and it wasn’t clear which parts of that duplication customers depended on versus which had gone unused.
EVM and UTXO chains work fundamentally differently at the protocol level, so a single generic API risked losing native capabilities power users relied on, while keeping separate universal and native APIs per chain meant duplicating every fix and every new feature across the board. And whatever the new design looked like, existing customers were already live on the existing surfaces and could not be asked to absorb a breaking change.
Our approach
Five workstreams. A dedicated API per chain type.
We started with data, not opinion: what customers actually used, where the universal and native APIs duplicated each other on each chain, and what better-designed APIs would need to preserve for EVM and UTXO alike. Then we built the migration path to get every customer there safely.
01
Usage & data discovery
Audited real customer usage across the universal and native APIs on both EVM and UTXO chains. Which endpoints were actually being called, which schema fields were populated and read, and which parts had quietly gone unused.
02
Duplication mapping
Identified endpoints and schema objects returning materially the same data through the universal and native paths within each chain family: redundant surface area being built, secured and documented twice over, for every chain.
03
Data, endpoint & Kafka rationalisation
Cut unused data fields and unused APIs out of the estate based on measured usage rather than assumption, without touching anything a customer was still relying on. Ran the same usage-led discipline over the underlying Kafka topics, consolidating and right-sizing them alongside the API cleanup.
04
Chain-native design, config-driven extensibility
Built a UTXO API and an EVM API, each combining the simplicity of the universal interface with the native, chain-specific methods power users needed, and driven by config so additional protocols within each chain family can be added without new endpoints. Custom methods let customers opt into exactly the functionality they wanted rather than a fixed response shape.
05
Zero-disruption cutover
Built and ran a phased migration plan across every legacy surface: old and new endpoints running in parallel, versioned contracts, staged traffic shift, so every customer moved onto the new API with no interruption to their existing integrations.
The outcome
£1.2M saved. Every customer migrated. Nothing broken.
The API and Kafka estate is smaller, less duplicated, and built around what customers actually use. The saving is realised, not projected, and the cutover ran to completion without a single customer-facing interruption.
£1.2M in annual infrastructure cost optimisation, realised across the API and Kafka rationalisation combined
Full visibility into real customer usage across the universal and native APIs on both EVM and UTXO chains, for the first time
Duplicate endpoints and overlapping schemas, left behind by running a universal and native API per chain family, identified and consolidated
Unused data fields, endpoints and Kafka topics retired, shrinking the estate to what customers actually use
A UTXO API and an EVM API, each extensible by config to support additional protocols, with custom methods so customers can choose exactly the functionality they need
Every customer migrated to the new endpoints with zero service interruption
We had a universal and native API for each of our EVM and UTXO chains, plus Kafka topics we’d never gone back to clean up, and no real idea which parts customers relied on. DOD gave us the data to know what to cut, a UTXO API and an EVM API built to extend by config, and £1.2M off our annual infrastructure bill.
Recognise the problem?
If your API, data or Kafka estate has grown duplicated surfaces over time and nobody's sure what's safe to remove, the discovery work is the place to start. It's what tells you what to cut, what to keep, and how to migrate without your customers noticing, or your infrastructure bill staying where it is.