A trading bot can start with a very simple flow:
Market data → Strategy → Order
That is enough to validate an idea.
The architecture changes quickly when the system needs to make automated decisions from real-time market data.
Now the backend has to deal with:
- stale data
- missed events
- reconnects
- message ordering
- local state
- synchronization
- recovery
This is the market-data problem I'm working through while building a Polymarket trading bot.
The difficult part isn't simply receiving data.
It's maintaining market state that the execution system can trust.
The Market-Data Pipeline
The architecture I'm working toward is:
WebSocket / API
↓
Market Data Worker
↓
Event Processing
↓
Market / Orderbook State
↓
Queue / Redis
↓
Strategy / Execution
The important boundary is between raw incoming data and trusted market state.
I don't want strategy or execution logic to understand transport-level details.
The market-data layer should absorb those concerns first.
Receiving Data Is the Easy Part
A WebSocket connection can be established in a few lines of code.
The harder questions start after that.
What happens when the connection drops?
What happens when messages are missed?
What happens when the application reconnects?
What happens when local state no longer represents the market correctly?
A trading system has to assume these situations will eventually happen.
That changes the way I think about the WebSocket layer.
Its job isn't just:
"Receive messages."
Its job is:
"Maintain a reliable stream of market events."
Market Data Worker
I prefer to isolate transport handling in a dedicated worker.
Conceptually:
WebSocket / API
↓
Market Data Worker
↓
Normalized Events
The worker can handle responsibilities such as:
- parsing incoming messages
- validating data
- normalizing events
- tracking event timing
- detecting connection failures
- reconnecting
- forwarding processed events
This keeps the rest of the system independent from the details of the transport.
The strategy shouldn't need to know whether the market data came from a WebSocket message, a REST request or a recovery process.
It should consume a consistent representation of market state.
Event Ordering Matters
Real-time trading systems are sensitive to ordering.
Imagine receiving two updates:
Event A
An orderbook change.
Event B
Another orderbook change.
If the application processes them incorrectly, the resulting local orderbook can become inconsistent with the actual sequence of market events.
This means the market-data layer needs to think about:
- event ordering
- sequence information
- duplicated events
- missed events
- timestamps
- recovery
The exact implementation depends on the data source.
The architectural principle is more general:
Receiving an event does not automatically mean local state is correct.
Market State
After processing events, the application needs a representation of the current market.
That is where market state comes in.
Depending on the system, it can include:
- current prices
- orderbook state
- available liquidity
- timestamps
- relevant market metadata
The strategy should consume this state rather than raw transport messages.
The boundary becomes:
Raw Events
↓
Processed Events
↓
Market State
↓
Strategy
This makes the strategy significantly easier to reason about.
The Orderbook Problem
The orderbook deserves special attention because execution decisions can depend heavily on it.
An orderbook represents market state at a particular moment.
The application observes that state.
Then the execution system acts later.
The market may have changed between those two points.
So there are really two separate questions:
How quickly did the update arrive?
and
How old is the state when the decision is made?
Those are not the same thing.
A system can have low network latency and still make an execution decision using stale state.
A Real Problem I Encountered
I ran into this issue while building my Polymarket trading bot.
A stale-orderbook problem affected assumptions made during execution.
The interesting part wasn't simply detecting that the data was old.
The difficult part was deciding where the system should determine whether the state was still trustworthy.
I documented that problem separately:
Polymarket Trading Bot Execution: Fixing Stale Orderbook Fills
That experience pushed me toward a cleaner separation between:
Market Data
and
Execution
The market-data layer should maintain trustworthy state.
The execution layer should decide whether that state is valid for the action it wants to take.
Freshness vs. Latency
This distinction is becoming more important to me.
Latency answers:
How quickly did information move?
Freshness answers:
How old is the state I'm using?
Those are different measurements.
For automated trading, I care about things such as:
- event timestamp
- processing time
- state age
- last valid update
- recovery state
A useful execution rule may therefore depend on state freshness rather than network latency alone.
For example:
Current state
→ execution can continue
State too old
→ execution may need to pause or recover
The exact threshold depends on the strategy and system requirements.
Disconnect and Recovery
A reliable market-data pipeline has to assume that connections fail.
A simplified lifecycle might be:
CONNECTED
↓
DISCONNECTED
↓
RECONNECTING
↓
RECOVERING STATE
↓
SYNCHRONIZED
↓
READY
The difficult part isn't opening the socket again.
The difficult part is knowing whether the local state is trustworthy after the interruption.
If events were missed, the system may need to rebuild or resynchronize state before normal execution can resume.
State Reconstruction
Applications restart.
Workers crash.
Connections drop.
Deployments happen.
That means market state cannot be treated as something that always exists correctly in memory.
The system needs a recovery strategy.
Depending on the implementation, that can mean:
- rebuilding state from a snapshot
- replaying events
- requesting fresh state
- marking the system as temporarily unavailable
- preventing execution until synchronization is complete
The important principle is:
Don't silently execute from state you don't trust.
Queue and Redis
Once market events have been processed, they can be passed downstream.
A simplified architecture is:
Market Data Worker
↓
Market / Orderbook State
↓
Queue / Redis
↓
Strategy Worker
↓
Execution Worker
The queue creates a useful boundary between real-time ingestion and downstream processing.
It can also make the system easier to scale because market-data processing and execution don't need to be one large process.
Strategy Should Consume State
The strategy should focus on decisions.
For example:
Market State
↓
Strategy
↓
Execution Intent
The strategy should not need to know:
- how a WebSocket reconnects
- how events are normalized
- how orderbook recovery works
- how execution requests are retried
Those concerns belong elsewhere.
That separation keeps the trading strategy easier to change and test.
Execution Should Validate Its Inputs
Even after the strategy produces an execution intent, the execution system should not blindly assume everything is still valid.
The execution layer can evaluate:
- market-state freshness
- current position
- existing orders
- risk constraints
- execution conditions
The flow becomes:
Strategy
↓
Execution Intent
↓
Validation
↓
Execution
This makes the boundary between decision-making and order execution much clearer.
Monitoring the Market-Data Layer
A real-time data pipeline should be observable.
Useful measurements include:
- time since last update
- event-processing latency
- reconnect count
- recovery duration
- processing errors
- state age
- queue depth
These metrics help distinguish different failure modes.
For example:
The data source is slow
is not the same problem as:
The application is behind
which is not the same as:
Local market state is invalid
Without observability, those problems can look identical from the outside.
What This Changes in the Trading Backend
Once market data is treated as a state-management problem, the architecture becomes much clearer.
Instead of:
WebSocket → Strategy → Order
I think in terms of:
WebSocket / API
↓
Market Data Worker
↓
Market / Orderbook State
↓
Strategy
↓
Execution
↓
Order Management
↓
Reconciliation
The market-data system becomes an explicit dependency of the trading engine.
That makes the overall system easier to debug, test and extend.
The Main Lesson
The biggest lesson for me is simple:
A live connection does not guarantee trustworthy market state.
Real-time trading infrastructure needs to care about:
- freshness
- ordering
- recovery
- synchronization
- state validity
The goal isn't merely to make market data arrive quickly.
The goal is to know whether the trading system has the right state before it acts.
That's the part of Polymarket trading infrastructure I'm continuing to explore.
What's Next
I'm continuing this series around the engineering behind a production-oriented Polymarket trading bot.
Next I'm going deeper into:
- orderbook processing
- execution architecture
- TWAP
- order management
- reconciliation
- monitoring
- trading-system backend design
Related Work
Polymarket Trading Bot Execution: Fixing Stale Orderbook Fills
Polymarket Trading Bot Architecture: From Market Data to Order Execution
