Heuristic:Nautechsystems Nautilus trader Cache Buffer Interval Tuning
| Knowledge Sources | |
|---|---|
| Domains | Optimization, Infrastructure |
| Last Updated | 2026-02-10 08:30 GMT |
Overview
Performance tuning parameter for cache write buffering, with a recommended range of [10, 1000] milliseconds and an optimal compromise at 100ms.
Description
The `CacheConfig.buffer_interval_ms` parameter controls the interval between pipelined/batched write transactions to the cache database backend (e.g., Redis, PostgreSQL). When set, cache writes are buffered and flushed at the specified interval rather than being written immediately. This batching significantly reduces I/O overhead for high-frequency trading scenarios where many state updates occur per second.
When set to `None` (the default), buffering is disabled and writes are immediate.
Usage
Use this heuristic when:
- Running live trading with a Redis or PostgreSQL cache backend
- Operating high-frequency strategies that generate many order/position state updates
- Experiencing high latency from cache write operations
- The cache backend is on a separate host (network latency amplifies per-write cost)
The Insight (Rule of Thumb)
- Action: Set `buffer_interval_ms` in `CacheConfig`.
- Value: The recommended range is [10, 1000] milliseconds. A good compromise is 100 milliseconds.
- Lower bound (10ms): Maximum write responsiveness while still providing some batching benefit.
- Upper bound (1000ms): Maximum batching benefit but state may be stale for up to 1 second after a crash.
- Trade-off: Higher intervals reduce I/O load but increase the risk of data loss on crash (unbuffered writes since last flush are lost). Lower intervals provide better durability but less batching benefit.
Reasoning
In a high-frequency live trading system, order fills, position updates, and account state changes can occur hundreds of times per second. Writing each update individually to a database creates significant I/O pressure, especially over network connections. Buffering batches these writes into periodic flushes, reducing the number of round-trips by orders of magnitude.
The 100ms compromise means that at most 100ms of state updates could be lost in a crash. For most trading strategies, this is acceptable because the reconciliation engine will recover the authoritative state from the exchange on restart.
Code Evidence
Parameter documentation from `cache/config.py:39-42`:
buffer_interval_ms : PositiveInt, optional
The buffer interval (milliseconds) between pipelined/batched transactions.
The recommended range if using buffered pipelining is [10, 1000] milliseconds,
with a good compromise being 100 milliseconds.
Default value from `cache/config.py:67`:
buffer_interval_ms: PositiveInt | None = None