FinTech Sector
Engineering the Nexus Global Trading Platform
A reference build: how we would take a decade-old trading system off a shared database and onto an event-sourced, edge-deployed architecture without pausing the market.
Design targets, not measured results
< 5msp99 order-path target
3 AZActive-active by design
100%Trades replayable from the log
The Fragmentation Bottleneck
The brief: a trading platform that had outgrown infrastructure written a decade ago. Regional databases in separate data centres that never quite agreed with each other, and latency that spiked exactly when the market did, which is the only time it matters.
- warningRegional nodes drifting out of sync under write pressure.
- warningA monolith where every release is a market-hours risk.
Where The Risk Actually Is
Three questions we would settle before drawing a single service boundary, because getting any of them wrong is a rewrite rather than a refactor.
memory
Compute Proximity
How much of the latency budget is physics? Distance between order origin and matching engine sets the floor, and no amount of application tuning moves it.
data_object
Event-Driven Flow
An asynchronous mesh so services fail in isolation. If market data stalls, order routing does not go down with it.
security
Zero-Trust Protocol
Per-service authorisation and encryption on internal hops, designed so the check costs microseconds rather than milliseconds.
Build Sequence
Build Sequence
01 / 03
Phase 1: Microservices Deconstruction
Strangle the monolith. Extract the highest-load paths first, order routing and market data, into Go services behind the existing gateway, so traffic moves incrementally and any step is reversible.
02 / 03
Phase 2: In-Memory Data Grid
A clustered cache holding hot market state, so the read path never touches disk. The consistency model is chosen explicitly here and recorded as an ADR, because it is the decision everything downstream inherits.
03 / 03
Phase 3: Resiliency & Chaos Testing
Kill nodes on purpose, in every environment, before production does it for us. Failover and zero-data-loss recovery are validated as tests rather than assumed as properties.
Stateless Edge Architecture
Order management decomposed into independent, edge-deployable nodes with Kafka as the spine. Executions process asynchronously but are recorded via event sourcing, so the ledger is the log, and any state in the system can be rebuilt by replaying it.
Technology Stack
GoKafkaRedisReactKubernetes
EDGE API GATEWAY
AUTH
ROUTING
DATA
DISTRIBUTED CLUSTER
Other reference builds
View All arrow_forwardRecognise your own system in this?
Then the next useful thing is forty-five minutes and a written brief on yours. Same format as this page, your constraints, and yours to keep either way.