AI × Quant Trader Series — Day 19¶
What is Event-Driven Architecture?¶
Reading time: ~18 minutes
Prerequisites: Shared Memory IPC, Lock-Free Programming, What is Market Data, What is an Order Management System (OMS)
Focus: understanding the architectural pattern behind modern electronic trading systems
Part 1: Introduction¶
Modern trading systems rarely execute code in a fixed sequence.
Instead, they spend most of their time waiting.
Waiting for:
- Market data
- Execution reports
- Risk updates
- Network messages
- Timer events
When something happens,
the system reacts.
This architectural style is known as Event-Driven Architecture (EDA).
Rather than asking:
What should happen next?
An event-driven system asks:
What just happened?
Every new event triggers the next action.
This simple idea forms the foundation of nearly every modern High Frequency Trading platform.
Part 2: What is an Event?¶
An event represents something that has already happened.
Examples include:
- Market data received
- New order submitted
- Order accepted
- Order filled
- Position updated
- Risk limit exceeded
- Connection established
- Timer expired
Events describe facts.
They do not contain business logic.
Instead, they notify the system that something has changed.
Part 3: Event-Driven vs Request-Driven¶
Many traditional applications are request-driven.
Example:
The application waits for a request before doing anything.
Trading systems are different.
The entire system reacts continuously to incoming events.
Nothing waits for user interaction.
Part 4: A Simple Trading Event Flow¶
Suppose the market publishes a new trade.
A successful execution generates another event.
Every step produces new events.
The trading system behaves like a chain reaction.
Part 5: Why Event-Driven Architecture?¶
Modern markets generate enormous numbers of events.
A single cryptocurrency exchange may publish:
- Millions of order book updates
- Hundreds of thousands of trades
- Thousands of executions
every second.
Polling these changes continuously would waste enormous CPU resources.
Instead,
the exchange pushes events only when something changes.
The trading system reacts immediately.
This model is naturally efficient.
Part 6: Loose Coupling¶
One of the biggest advantages of Event-Driven Architecture is loose coupling.
Instead of calling each other directly,
components communicate through events.
Each component decides independently whether it cares about a particular event.
New functionality can often be added without modifying existing components.
Part 7: Event Pipelines¶
A production trading platform is essentially a pipeline of events.
Exchange
↓
Market Data Event
↓
Order Book
↓
Strategy
↓
Signal Event
↓
Execution Engine
↓
Order Event
↓
OMS
↓
Execution Report
↓
Position Update
↓
Risk Update
Every stage transforms one event into another.
This architecture is highly modular and naturally scalable.
Part 8: Event Queues¶
Events must travel between components efficiently.
Typical implementations include:
- Lock-Free Queues
- Ring Buffers
- Shared Memory
- Message Queues
High Frequency Trading systems usually avoid heavyweight messaging systems because every additional layer increases latency.
Instead,
lightweight in-memory event queues are preferred.
Part 9: Deterministic Processing¶
Professional trading systems process events in a deterministic order.
For example:
Changing this sequence may produce different trading results.
For this reason,
many HFT systems rely on single-threaded event loops within individual components while using parallelism across independent components.
Deterministic processing simplifies debugging and improves reproducibility.
Part 10: Event-Driven Systems in High Frequency Trading¶
Every important activity inside a trading platform is an event.
Examples include:
- Market updates
- Order submissions
- Order cancellations
- Fill notifications
- Risk alerts
- Timer callbacks
- Network reconnects
Rather than continuously checking system state,
components simply react when events arrive.
This makes the architecture both responsive and efficient.
Part 11: Where godzilla.dev Fits¶
The architecture of godzilla.dev is built around event-driven principles.
Market data, execution reports, risk updates, and internal state changes are represented as events flowing through independent components.
This approach provides several advantages:
- Clear separation of responsibilities
- Easier extensibility
- Better scalability
- Lower coupling
- Predictable execution flow
By combining event-driven architecture with shared memory and lock-free communication, the framework enables trading systems to process large volumes of market events while maintaining deterministic low-latency behavior.
Part 12: Key Takeaways¶
Event-Driven Architecture organizes software around events rather than sequential function calls.
Instead of repeatedly asking whether something has changed, components react only when new events arrive.
For modern trading systems, this approach provides:
- Better scalability
- Lower latency
- Cleaner architecture
- Reduced coupling
- More predictable behavior
Nearly every professional electronic trading platform is fundamentally an event-driven system.
What's Next?¶
The next article explores another important optimization used throughout low-latency systems:
- What is Zero-Copy Messaging?