Real-Time Market Data Systems

Context

Six-month internship as an Intern Software Engineer on the Market Backend team at GTN Technologies, Colombo. The team builds the servers behind a trading and investment platform used by brokerages and fintech apps across several continents: prices arrive from stock exchanges around the world, and those servers check them, process them and deliver them to the apps people trade from.

In that setting a wrong or late number is not a cosmetic bug - it is what an investor sees when they decide to buy or sell. Most of my work was about making sure the data is right, and being able to prove it.

This page describes the kind of work, not the company's systems. Internal names and architecture details stay with the company.

A testing tool for live price feeds

Trading apps receive prices over a long-lived WebSocket connection rather than by refreshing a page. I built a full-stack tool - Spring Boot backend, React frontend - that lets QA engineers and developers run structured checks against that connection: logging in, subscribing to instruments, and confirming every message type arrives in the right shape.

Test runs are queued per user, so several people can use it at once without interfering with each other
Scenarios are described in YAML profiles instead of being hard-coded
Results are archived to AWS S3, so past runs can be reviewed later
Market-hours aware - it knows whether an exchange is open before judging its data

One set of data-quality rules, shared

Several internal monitoring dashboards each needed to answer the same questions: is this exchange open right now, and has this price gone stale? I extracted that logic into a reusable Java / Spring Boot library - exchange calendars, market hours, staleness detection - and integrated it into two of those dashboards.

Before switching one over, I ran the old and new versions side by side on live market data and compared their verdicts. Along the way the dashboards gained a live market-status view, JWT-secured login with Spring Security, online editing of validation rules, and a history of past checks. That work also meant upgrading Java and Spring Boot versions and clearing dependency security warnings.

Live trading statistics at scale

The largest project was a service that maintains a running average trade price for thousands of stocks at once - weighted by how many shares changed hands, and updated the moment each trade happens (in trading this is called VWAP). It needs to be fast and exactly right, because other systems quote it directly.

Prototyped the calculation inside Redis using Lua scripts, which run atomically and so avoid race conditions between concurrent trades
Benchmarked competing designs against the most-traded symbols and let the numbers choose the architecture
Connected the service to the existing data platform through Apache Kafka producers and consumers, with JUnit tests around both the calculation and the messaging
Built a comparison harness and a small testing UI that checked the new service's output, symbol by symbol, against the system it was replacing - and traced the few mismatches to their cause
Handed over with an architecture document, an interface spec, an operations runbook and a deployment verification script

Smaller pieces

Hardened a Bash deployment check that catches broken or duplicate packages before they reach a server
Analysed message timing logs with Python, pandas and matplotlib in Jupyter
Local environments in Docker; everything shipped through GitLab merge requests, code review and peer testing on QA servers

What I took from it

Industrial software has to be correct, observable and maintainable at a level coursework rarely asks for. The habit I kept is measuring before deciding: the benchmark, not intuition, picked the design - and a side-by-side comparison, not a passing test suite, is what made anyone trust the new service.