THE SITUATION

A platform built for a different era

The client had been running energy trading operations on an Oracle-based monolithic platform for over a decade. It had served them well — but the business had grown faster than the architecture could handle. Position data arrived a day late. Infrastructure costs were climbing. And any change to one part of the system risked breaking another.

The immediate trigger was a Trayport API migration — a hard deadline that forced the question: patch the existing system, or rebuild properly? They chose to rebuild.

<aside> 💡

T+1 position updates Trading decisions being made on yesterday's data — a significant risk exposure in volatile markets.

</aside>

<aside> 💡

Monolithic architecture Every change required full regression testing. Deployment cycles were slow and risky.

</aside>

<aside> 💡

Rising infrastructure cost Oracle licensing and on-premise hardware costs scaling with data volumes, not with value.

</aside>

<aside> 💡

Trayport API deadline A hard migration deadline from a key market data provider — with no flexibility on timing.

</aside>

WHAT WE DID

Start with the data flow, not the technology

We started by mapping every data flow in the existing system before touching a single line of code. That mapping — understanding exactly what moved where, and what depended on what — is what made a zero-downtime migration possible.

1. Architecture mapping — Full audit of existing Oracle data flows, dependencies, and downstream consumers before any design decisions were made. Data flow mapping | Dependency audit | Downstream analysis
2. Streaming layer design — Designed a Kafka-based streaming architecture to replace batch ETL — with Flink handling real-time stream processing and position aggregation. Apache Kafka | Apache Flink | Stream processing
3. Trayport API migration — End-to-end migration of the Trayport integration onto the new platform — meeting the hard deadline without disrupting live trading operations. Trayport API | Market data integration | Zero downtime cutover
4. Cloud-native deployment — Migrated the full platform to AWS with independent microservices — replacing the monolith with components that could be scaled and deployed independently. AWS | Microservices | Cloud-native infrastructure

WHAT CHANGED

A platform the business can grow into

The migration delivered what the client needed — but more importantly, it delivered a platform that does not constrain what comes next.

<aside> 💡

Sub-second position tracking Position data now updates in sub-second intervals — down from T+1 batch. Trading decisions are made on current data.

</aside>

<aside> 💡

Zero downtime migration The full migration was executed without interrupting live trading operations — no maintenance windows, no data loss.

</aside>