1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
//! # Persistent Storage Abstraction Layer
//!
//! This module provides a unified abstraction layer for all storage subsystems
//! used by the Rift broker. Every broker component -- offset allocation, log
//! append, deduplication, and snapshot capture -- is backed by a single
//! [`StorageEngine`] that operates on opaque byte keys and values.
//!
//! ## Architecture Overview
//!
//! ```text
//! StorageEngine -- low-level byte-oriented key-value store (get/put/delete/scan_prefix)
//! +-- OffsetStore -- per-topic monotonic offset allocation (spec section 13.1)
//! +-- LogStore -- topic message log append, range query, and retention
//! +-- DedupeStore -- message deduplication (spec section 11.2)
//! +-- SnapshotStore -- topic state snapshot capture and retrieval (spec section 13.4)
//! ```
//!
//! ## Storage Engines
//!
//! This crate ships two engine implementations:
//!
//! - [`MemoryEngine`] -- an in-memory engine backed by `DashMap`. Requires no
//! configuration and provides no persistence; ideal for development, testing,
//! and single-process deployments.
//! - [`SledEngine`] -- a durable engine backed by the embedded B+ tree
//! database [sled](https://docs.rs/sled). Requires the `sled` Cargo feature
//! and is suitable for production use.
//!
//! ## Key Encoding
//!
//! Higher-level stores delegate key construction to the [`encode`] module.
//! Every key follows a two-level namespace of the form
//! `<topic_name>\x00<sub_key>`, where `\x00` is the [`encode::SEP`]
//! separator. This guarantees that scanning entries for topic `"room/5"`
//! never accidentally matches entries belonging to `"room/50"`.
//!
//! ## Choosing an Engine
//!
//! | Concern | `MemoryEngine` | `SledEngine` |
//! |---------|---------------|--------------|
//! | Persistence | None (lost on restart) | Disk-backed |
//! | Latency | Sub-microsecond | Low millisecond |
//! | Setup | Zero configuration | Requires a `sled::Db` path |
//! | Feature gate | Always available | `sled` Cargo feature |
/// The deduplication sub-module, which detects and discards duplicate
/// messages within a configurable time window (specification section 11.2).
///
/// See [`dedupe`] for details on the trait and its implementations.
/// Key-encoding helpers that construct byte-level keys for every
/// higher-level store (offset, log, deduplication, snapshot).
///
/// See [`encode`] for the full key format table.
/// The low-level byte-oriented key-value storage engine abstraction.
///
/// Provides [`StorageEngine`] and the two built-in backends
/// ([`MemoryEngine`] and `SledEngine`).
/// The topic message log store, supporting append, range queries, and
/// retention enforcement.
///
/// See [`log`] for the trait contract and implementation details.
/// The per-topic monotonic offset allocation store (specification section 13.1).
///
/// See [`offset`] for the trait contract and implementation details.
/// The topic state snapshot store, capturing and retrieving snapshots
/// (specification section 13.4).
///
/// See [`snapshot`] for the trait contract and implementation details.
// ── Memory-backed re-exports (always available) ───────────────
pub use ;
pub use ;
pub use ;
pub use ;
pub use ;
pub use ;
// ── Sled-backed re-exports (feature-gated) ────────────────────
/// Sled-backed deduplication store. Requires the `sled` Cargo feature.
pub use SledDedupeStore;
/// Sled-backed storage engine. Requires the `sled` Cargo feature.
pub use SledEngine;
/// Sled-backed log store. Requires the `sled` Cargo feature.
pub use SledLogStore;
/// Sled-backed offset store. Requires the `sled` Cargo feature.
pub use SledOffsetStore;
/// Sled-backed snapshot store. Requires the `sled` Cargo feature.
pub use SledSnapshotStore;