TradeLabs AILearn

Message Queues

Message queues pass market data, signals and orders between trading components. Learn pub sub and queues, tools like Kafka, Redis and ZeroMQ, and design trade offs.

Advanced3 min readUpdated 3 Oct 2026
Markdown
Lesson 6 of 16

As a trading system grows beyond one program, its parts need to talk: feed handlers publish prices, strategies consume them and publish orders, risk services check those orders and loggers record everything. Message queues and messaging systems carry these events between components. They decouple producers from consumers, absorb bursts and allow parts of the system to be restarted or scaled independently. The right choice depends on whether you need speed, durability or both.

Messaging patterns#

PatternHow it worksTrading example
Publish and subscribeProducers publish to topics; every subscriber gets a copyPrice updates sent to several strategies
Work queueEach message goes to one of several workersDistributing backtest jobs
Request and replyA request gets a direct responseAsking a risk service to approve an order
Event logMessages stored in order and can be replayedRecording all events for audit and replay. See Market Data Replay

Common tools#

ToolCharacterTypical trading use
Apache KafkaDurable, high throughput event log; consumers can replay historyData pipelines, audit streams, analytics
Redis (pub sub and Streams)In memory, simple, fastLive prices to dashboards, light messaging. See Redis and PostgreSQL for Trading
RabbitMQFlexible routing, reliable deliveryJob queues, back office workflows
ZeroMQA library for direct, brokerless messaging with low latencyFast links between processes
NATSLightweight, fast pub subService messaging
Shared memory ring buffersCustom, lowest latencyInside latency critical trading engines. See Lock-Free Programming and Ring Buffers

Durability versus latency#

NeedChoose
Every message stored and replayableKafka or Redis Streams with persistence
Lowest latency between processes on one machineShared memory or ZeroMQ over interprocess transport
Simple fan out of live pricesRedis pub sub or NATS
Reliable job distributionRabbitMQ or a work queue

Durability costs time: writing to disk and waiting for acknowledgements adds latency. Many systems use a fast path for trading and a separate durable path for recording.

Backpressure#

When consumers fall behind, something must give: messages queue up, get dropped or slow the producer. For market data, the latest price usually matters more than every intermediate one, so conflation (keeping only the newest update per symbol) is common for slow consumers. For orders and fills, nothing may be dropped. Decide this explicitly for each stream.

Ordering and duplicates#

Do you need a message queue?#

A single bot in one process can pass events through an in memory queue with no external system. Introduce messaging when you have several processes, need to record streams durably or want to scale parts independently. See Building Trading Bots.

Frequently asked questions#

What is a message queue in trading?#

A system that passes events such as prices, signals and orders between components, decoupling producers from consumers.

Is Kafka good for trading?#

Kafka is excellent for durable, replayable data pipelines and audit streams, but it is not usually used on the lowest latency trading path.

What is backpressure?#

What happens when consumers cannot keep up with producers; systems must queue, drop, conflate or slow messages, and the right choice depends on the stream.

Next, learn how Redis and PostgreSQL fit into trading setups in Redis and PostgreSQL for Trading.

Check your understanding

3 quick questions on this lesson. Get them all right to finish it.

Turn on JavaScript to take the quiz.

Finished this lesson?Sign in to save your progress across devices.
Next lessonRedis and PostgreSQL for TradingHow Redis and PostgreSQL work together in trading systems: Redis for live prices, caches and state, PostgreSQL for durable orders, fills and history.

Mentioned in