For the first two years I worked in trading infrastructure, I didn't really understand trading. I understood the systems. I understood the networks, the databases, the latency requirements, the disaster recovery plans. I could tell you exactly what happened technically when an order left our system. But I couldn't have told you what happened to it after that, or why the timing of when it left mattered so much.
This is, I think, a common situation for engineers who end up in financial services without coming from a finance background. You learn the technical layer thoroughly and treat the business layer as something the traders deal with.
About three years into my first role in this space, I decided to actually learn the thing I was building infrastructure for. This post is my attempt to explain market microstructure the way I wish someone had explained it to me - in plain terms, from the ground up.
What "the market" actually is
When people say "the stock market," they talk about it as if it's a single place. It isn't. It is a collection of exchanges - electronic venues where buyers and sellers meet - plus a network of brokers, dark pools, and other trading venues that all connect together.
In the US, there are around 16 registered stock exchanges and many more alternative trading venues. When you buy a share of a company, your order might be executed on the New York Stock Exchange, or NASDAQ, or one of a dozen other venues, depending on which venue is offering the best price at that moment and which route your broker chooses.
This matters for engineering because trading systems have to be connected to multiple venues simultaneously, receiving price information from all of them, making routing decisions in real time, and executing orders across them in a coordinated way.
The order book: the fundamental data structure of trading
Every exchange maintains something called an order book. This is a list of all the orders that have been placed but not yet matched.
On one side of the book are buy orders: everyone who wants to buy shares, and the price they're willing to pay. On the other side are sell orders: everyone who wants to sell, and the price they're willing to accept.
The highest price any buyer is willing to pay is called the "bid." The lowest price any seller is willing to accept is called the "ask" (or "offer"). The difference between these two prices is called the "spread."
When a buy order comes in at a price that matches a sell order, a trade happens. The orders are removed from the book and the transaction is recorded.
The order book changes continuously throughout the trading day, sometimes thousands of times per second on busy exchanges. Building a system that maintains an accurate, low-latency picture of the order book across multiple venues is one of the genuinely hard engineering challenges in this space.
Why latency is measured in microseconds
A microsecond is one millionth of a second. This is not a meaningful unit of time for most human activities. It is an extremely meaningful unit of time in certain types of trading.
Here is why: if you can see the order book faster than the people you are trading against, you have a genuine informational advantage. If you know that a large buy order is about to hit a particular exchange and you can react before the price adjusts, you can trade profitably on that information.
This is why trading firms spend significant money on co-location services (physically placing their servers in the same building as the exchange's servers, reducing the physical distance data has to travel), custom network hardware, and software optimized down to the assembly language level.
As an engineer supporting this infrastructure, understanding why these investments are made changed how I thought about what "good enough" meant. A 10ms improvement in response time on a consumer web application is nice. A 10ms improvement in trading order submission can be worth millions of dollars per year, or nothing, depending on the trading strategy. The business context determines what "good enough" actually means.
What changed about how I work
Understanding the business - really understanding it, not just the technical surface - changed a few specific things about how I do my job.
I started asking different questions in architecture meetings. Instead of "will this perform well enough," I started asking "what is the latency budget for this leg of the trade, and what does a 5ms improvement here actually buy the business?" Sometimes the answer was that it bought very little, and we could make simpler choices. Sometimes the answer was that it bought a lot, and we needed to be more careful.
I got better at translating between technical and business language. When a trader told me something was "too slow," I could ask specific questions about what they were seeing and connect it to a specific part of the system rather than running generic performance investigations.
And I stopped treating the trading infrastructure as a black box that happened to have financial data flowing through it. It is a trading system, and understanding trading made me better at building the infrastructure that serves it.
If you work in financial services infrastructure and haven't taken the time to properly learn the business layer, I'd encourage you to do it. It doesn't require a finance degree. It requires curiosity and a few weeks of reading. The return on that investment, in terms of how you think about your work, is significant.
