A reference architecture for a small prop desk's trading system

This is for a desk of two to ten traders, running a handful of strategies across several accounts at one or two brokers, unattended for most of the session, without an institutional OMS budget. The diagram below is the shape we build to for that desk. The rest of the page explains each box, the failure it prevents, and what you can leave out at first. There is no strategy in it anywhere; that is the desk's own business.

The data service

One process owns market data for the whole desk. It subscribes to the feed and to the broker's own quotes, normalises symbols and timestamps, builds closed bars where strategies want bars, fills gaps it can and flags the ones it cannot, and, above all, detects a stale feed. A price that stopped updating three minutes ago looks exactly like a live price to a strategy engine; the data service is the only thing that knows the difference. Every strategy reads from it, none of them connects to a feed directly, so a feed change or a new vendor is one change, not five.

Strategy engines, one process each

Each strategy runs as its own process with its own parameters, instruments and account mapping. The engine's only outputs are order intents: "buy this much of that, for this account, because of rule X". It never talks to a broker. The separation is what lets one strategy be restarted, paused or replaced while the rest keep running, and it is what keeps the desk's strategy logic private to the engine's author. We build the engine around the rules the trader writes down; the rules are theirs.

The risk gate

Every order intent passes through one gate before it can become an order. The gate holds the limits the desk sets per account and per strategy: maximum position, maximum daily loss, maximum order size, allowed instruments and hours. It also holds the kill switch, one setting that stops every new order across the desk, and a per-strategy version of the same. The gate is deliberately boring code, reviewed more carefully than anything else in the system, because it is the last thing between an engine bug and the market.

The order manager

The order manager turns an approved intent into a broker order and then owns that order's life: submitted, acknowledged, partially filled, filled, cancelled, rejected. It is a state machine, not a function call. It gives every order an idempotency key so a retry after a timeout cannot double-send, it handles partial fills without re-sending the filled part, and it decides what to do when a broker is down: queue with an expiry, or drop and alert. Most of the engineering in a live system lives here and in the risk gate, not in the strategies. Our edge-cases guide lists what it has to survive.

Broker adapters

One adapter per broker, all with the same interface: place, modify, cancel, and read back orders, fills and positions. Behind the interface is whatever the broker offers: a FIX session, a REST and socket API, or a vendor bridge. Because the order manager only sees the interface, adding a second broker or replacing one is adapter work, not a rewrite. Which interface is right for each broker, and when FIX earns its extra setup, is on our broker API integration page.

Position store and reconciliation

The system keeps its own record of what every account holds, and a loop compares that record against what the broker reports, continuously during the session and once more at the close. When they disagree, the broker is the source of truth and the desk is alerted; trading on the wrong position is how small errors become large ones. This is the component small desks most often skip, and the one we never let them skip.

Audit log, monitoring and the admin view

The audit log records every signal, every risk decision, every order state change and every fill, append-only, with timestamps. It is how "what happened at 10:42?" gets answered a week later, and it is what a broker or auditor asks for. Monitoring watches heartbeats from every process, stale-data flags, reject rates and the reconciliation loop, and pages someone when they drift. The admin view, a page that shows positions, orders and the kill switch, is genuinely optional at the start; a log file and a terminal do the job for the first months.

Two stores, on purpose

Ticks and bars go in a time-series store built for append-heavy, range-query workloads. Orders, fills and positions go in a relational store where transactions and constraints matter. Putting both in one database is a common early shortcut that becomes the first thing rewritten. Neither needs to be exotic; what matters is that the order store is durable across a crash and the tick store can drop or archive data without touching it.

Deployment

One virtual machine in the broker's region, or one per region when a desk trades two continents. A scheduler wrapped around the exchange calendar starts and stops the processes, because most broker APIs, and every Indian one, require a fresh login each day. Secrets stay in the environment or a secrets manager, never in code. A daily restart before the open is a discipline, not a workaround. Whether any of this needs co-location is answered in our infrastructure sizing guide: for a small desk, almost always no.

What to leave out at first, and what not to

• Leave out for now: the admin view, a second broker, FIX where REST will do, a message bus between components (function calls inside one service are fine until they are not).
• Never leave out: the risk gate, the kill switch, idempotent orders, reconciliation, and the audit log. These are the difference between a demo and a system, and they are cheapest to build first.

How this maps to what we build

The order manager and adapters are our execution engines work; the whole diagram across several accounts and brokers is a multi-broker platform; the version with an institutional OMS or EMS in the middle is on our institutional trading systems page. Our multi-broker platform case study shows one built out in full. We build to the desk's specification, we do not supply strategies or trading calls, and we make no claim about returns.