backend.hpp File Reference

Storage backend interface: what a session's fills, orders, positions, PnL and kill events are handed to, so they can be queried without replaying the journal. More...

#include "fastmm/config/config.hpp"
#include "fastmm/core/engine_runner.hpp"
#include "fastmm/core/enums.hpp"
#include "fastmm/core/instrument.hpp"
#include "fastmm/core/record_stream.hpp"
#include "fastmm/core/result.hpp"
#include <cstdint>
#include <span>
#include <string>
#include <string_view>
#include <vector>

Go to the source code of this file.

Classes
struct	fastmm::store::BackendOptions
	What a backend is built with. More...
struct	fastmm::store::SessionOpen
	Written once, before any record. More...
struct	fastmm::store::SessionOpen::ParamField
	The strategy's parameter table in schema order: a ParamRecord's field index names an entry. More...
struct	fastmm::store::SessionOpen::ParamValue
	The parameters the session starts with. More...
struct	fastmm::store::SessionClose
	Written once, after the last record. More...
class	fastmm::store::Backend

Namespaces
namespace	fastmm
namespace	fastmm::store

Detailed Description

Storage backend interface: what a session's fills, orders, positions, PnL and kill events are handed to, so they can be queried without replaying the journal.

engine thread --RecordWriter--> MsgRing --StoreThread--> Backend --> rows

The journal stays the byte-exact stream a replay consumes (core/journal.hpp); a backend holds the interpreted record. Backends are selected by name from [storage] backend and built by the registry (store/registry.hpp); "sqlite" ships with FastMM and "none" means no backend at all.

What a backend must guarantee (docs/reference/storage.md):

• Ordering. Records arrive in the order the engine made them, on one thread, and seq is strictly increasing within a session. Calls between begin() and commit() are one batch.
• At most once. A record the ring dropped, or a batch the process died inside of, is gone; a backend must not invent one. Records carry keys (session id + seq, and an exec id on a fill) so re-ingesting the same record is a no-op.
• Never block the caller for long. StoreThread runs the backend on its own thread, so a slow commit costs ring space, not engine latency, but a backend that blocks for seconds will overflow the ring and lose records.
• Never throw across the interface, and never abort the process. A failure is counted in errors() and described by last_error(); the session keeps trading.

Everything here runs off the engine thread and may allocate.