Velocity Trader

Project Overview

Velocity Trader is the trading front end we built for a desk that had simply run out of patience with spreadsheets, shared files, and half a dozen browser tabs that were never quite in sync. Traders open one place: live charts, depth, a blotter, and positions that update as the market moves. Supervisors and compliance get their own views enough to see what happened, without handing them keys they should not have. Underneath it is ordinary product discipline: if someone asks who approved a trade or changed a limit three weeks ago, the answer should be in the system, not in someone's inbox.

Problem

A lot of the workflow lived in muscle memory. People pulled numbers from vendor screens, dropped them into sheets, and hoped nobody fat-fingered a row. When two people had two different versions of "the book," nobody noticed until P&L did not tie out. Risk was fuzzy. Limits existed on paper, but there was no single place that knew, in real time, whether a trader was inside the guardrails or who was supposed to step in when they were not. When feeds lagged or a tab froze, it always seemed to happen in the first minute after the open, or right on a headline. And every time compliance asked for a straight story (who clicked what, and when), the team had to glue logs together by hand. That is slow, and it does not scale. They did not want a five-year vendor migration. They wanted something they could ship, use, and grow.

Solution

We put the day-to-day work into one Next.js app. Charts and tables subscribe over WebSockets so prices and orders refresh without the trader hammering refresh. It sounds small; it is the difference between trusting what you see and guessing. Orders go through a Node service we own: place, cancel, amend, and persist the state in Postgres so there is one source of truth. Redis sits in front for the stuff that should not hit the database on every keystroke sessions, throttling, short-lived cache. Permissions are boring on purpose. Traders trade. Other roles can watch or audit. The checks run on the server, not only in the browser, so nobody gets around them by opening DevTools. We ship it in containers so when volume spikes, we can add capacity without rewriting the app. Nothing here is magic just pieces connected so the happy path stays fast and the paper trail stays honest.

Technology Stack

Next.jsNode.jsPostgreSQLWebSocketRedisDocker

Architecture

Think of it in three layers. The browser loads the app, then opens a WebSocket back to our API for anything that needs to move in real time. REST handles the rest login, settings, anything that does not belong on a live stream. The API tier owns business rules: validate an order, apply limits, write the result. Postgres stores orders, positions, and audit rows we care about keeping forever. Redis is the scratch pad sessions, rate limits, a bit of caching so we are not writing to disk for every tick. Market data comes in on its own path so a noisy chart does not block an execution. We keep containers small and boring so we can run more of them when the desk is busy. Kubernetes is there for scaling and rolling deploys; the point is not buzzwords, it is that nobody should lose a Friday because one box got hot.

Results

• 60% faster order execution vs legacy system
• Real-time P&L visibility for 200+ traders
• Full audit trail for regulatory compliance