reckon_db_subscription_backend behaviour (reckon_db v3.1.1)
View SourceBehaviour for pluggable subscription-state backends.
Subscription checkpoints track WHERE each consumer is in a stream (or global log). They are written frequently — every ack — but are small and not latency-critical. Most storage backends can handle them fine; the behaviour exists so that a backend can choose whether to keep checkpoints in its own store or delegate to the Khepri control plane.
The default implementation (reckon_db_khepri_subscription_backend) stores checkpoints in Khepri. This is the natural fit — subscription state IS a control-plane concern, and Ra consensus on checkpoints is exactly what you want for "don't replay already-acknowledged events on leader failover."
Fast log backends (RocksDB, custom) will typically implement reckon_db_log_backend but NOT this — they defer to the Khepri implementation. Having the behaviour explicit makes the split clean.
Summary
Types
Callbacks
-callback ack(state(), Name :: binary(), Selector :: term(), Checkpoint :: non_neg_integer()) -> ok | {error, term()}.
-callback close(state()) -> ok.
-callback get(state(), Name :: binary()) -> {ok, subscription()} | {error, not_found} | {error, term()}.
-callback list(state()) -> {ok, [subscription()]} | {error, term()}.