Why Shared Memory Matters in Low-Latency Trading Systems | Trading Engineering #7

Why Shared Memory Matters in Low-Latency Trading Systems

 

Trading Engineering Series — 07

In low-latency trading systems, performance is not determined solely by CPU speed or network latency.

How data is transferred inside the system—and how many times it is copied or synchronized—can also have a significant impact on overall latency.

This becomes particularly important when market data and order information move between multiple processes.

In such environments, Shared Memory is one of the key technologies that can be used to build efficient inter-process communication.

---

1. Why Does Inter-Process Data Transfer Matter?

A typical trading system consists of multiple processes, each responsible for a specific function.

For example:

Market Data Process → Strategy Process → Order Process → FEP Process

As data moves between these processes, various operations may be required:

• Data copying
• IPC processing
• System calls
• Context switching
• Buffer management
• Synchronization

The more frequently data moves between processes, the more these overheads can accumulate.

In high-throughput trading environments, even relatively small processing costs can become significant when repeated thousands or millions of times.

---

2. Traditional IPC and Data Copying

Consider a simple case where Process A needs to send data to Process B.

A conventional architecture may look like:

Process A → Buffer → IPC → Process B Buffer

Depending on the IPC mechanism, the same data may be copied between multiple memory areas.

For example:

Network Buffer → Application Buffer → IPC Buffer → Strategy Buffer

When message frequency is high, these repeated memory operations can become an important part of the processing cost.

---

3. What Is Shared Memory?

Shared Memory allows multiple processes to access the same memory region.

Conceptually:

 

Process A
         ↓
Shared Memory
         ↑
Process B

 

Process A writes data into the shared memory region, while Process B can access the same data without requiring a separate copy into its own process memory.

When designed properly, this can significantly reduce unnecessary data movement between processes.

For this reason, Shared Memory is widely considered an important technique for efficient IPC in latency-sensitive systems.

---

4. Shared Memory and Ring Buffers

One common data structure used with Shared Memory is a Ring Buffer.

The basic concept is:

Producer → Ring Buffer → Consumer

 

The Producer writes data into the buffer, while the Consumer reads it.

Because the buffer is reused in a circular manner, it can efficiently handle continuous streams of market data or events.

For example:

Market Data Process
↓
Shared Memory Ring Buffer
↓
Strategy Process

This architecture can be particularly useful when market data arrives continuously at a high rate.

---

5. Why Minimizing Locks Matters

Using Shared Memory does not automatically make a system faster.

Because multiple processes access the same memory region, synchronization becomes an important design consideration.

For example, if a Producer and Consumer access the same data simultaneously, some mechanism is required to ensure data consistency.

Using Mutexes or other locks indiscriminately can introduce additional latency.

Depending on the architecture, several approaches may be considered:

• Single Producer / Single Consumer
• Minimal locking
• Short lock scopes
• Atomic operations
• Ring buffers
• Explicit data ownership

The key point is that Shared Memory itself is not the optimization.

The way data is shared and synchronized is what determines its effectiveness.

---

6. The Single-Writer Approach

Another important design principle is to avoid having multiple processes modify the same data simultaneously whenever possible.

For example:

Writer 1 → Data
Writer 2 → Data
Writer 3 → Data

This can make synchronization significantly more complex.

A different approach is:

Single Writer → Data → Multiple Readers

With clear ownership of the data, the system can reduce synchronization requirements and make its behavior more predictable.

Of course, Single Writer is not suitable for every architecture. The appropriate design depends on the characteristics of the data and processing model.

---

7. Does Every Component Need Shared Memory?

No.

Shared Memory is not always the best solution.

For systems with relatively low message frequency or less stringent latency requirements, conventional IPC mechanisms or message queues may be simpler and more appropriate.

For example:

• Low message frequency
• Non-latency-critical workloads
• Strong process isolation requirements
• Simpler operational requirements
• Lower architectural complexity

Shared Memory can provide performance advantages, but it can also increase architectural and operational complexity.

The goal is therefore not to use Shared Memory everywhere.

The goal is to use it where it provides meaningful benefits on the latency-critical path.

---

8. Where Can Shared Memory Be Used in Trading Systems?

A low-latency trading architecture might look like:

Market Data
↓
Shared Memory
↓
Strategy
↓
Shared Memory
↓
Order Manager
↓
DMA / FEP
↓
Exchange

The connection between Market Data and Strategy can be particularly latency-sensitive because market data may arrive at a very high frequency.

Similarly, Shared Memory can be used between the Strategy and Order Manager when fast signal delivery is required.

---

9. Considerations for C-Based Systems

In C-based low-latency systems, the memory layout itself can have a significant impact on performance.

Important considerations may include:

• Fixed-size data structures
• Memory alignment
• Cache efficiency
• Buffer layout
• False sharing
• Atomic operations
• Memory ordering

When multiple CPU cores are processing shared data, simply placing data in Shared Memory is not enough.

CPU cache behavior and memory access patterns must also be considered.

In other words, Shared Memory optimization requires consideration of:

IPC Design + Memory Design + Synchronization Design

---

10. Shared Memory and Reliability

Performance is only one part of a production trading system.

Failure scenarios must also be considered.

If one of the processes using Shared Memory terminates unexpectedly, the system needs to handle issues such as:

• Shared memory state
• Producer / Consumer state
• Buffer position
• Message sequence
• Process restart
• Recovery

Therefore, Shared Memory architectures should be designed not only for normal operation, but also for fault recovery and process restart.

---

11. Our Approach at FontesFintech

At FontesFintech, we consider data movement itself to be an important part of low-latency system design.

Our approach includes:

• Minimizing unnecessary memory copies
• Efficient IPC design
• Shared Memory
• Ring Buffer-based data transfer
• Minimizing lock and synchronization overhead
• Considering cache efficiency
• Clear data ownership
• Fault recovery and restart handling

The goal is not to use a particular technology simply because it is fast.

The important question is:

Where does the data go, and what does it cost to move it?

By analyzing the actual critical path of a trading system, we can determine where optimization will have the greatest impact.

---

Conclusion

The performance of a low-latency trading system is not determined by CPU or network performance alone.

How data moves between processes can also become a critical factor.

Less Copy
Less Lock
Less Overhead

Shared Memory is one powerful technique for achieving these goals.

However, Shared Memory should never become the objective itself.

The architecture should be designed around the characteristics of the trading system, the data flow, and the actual latency requirements.

Ultimately, a well-designed low-latency trading system is not simply a system that uses fast technologies.

It is a system where data follows the most efficient path possible.