Event sourcing on Streams.

A row says what is true now. A log says everything that ever happened, in order. Event sourcing keeps the log and derives the row: nothing is overwritten, every transition is appended, and the present is reconstructed by folding the log from the start. A Redis Stream is the structure — an append-only sequence of entries, each with a time-ordered id that orders it against every other.

Three properties follow, and they are the three dives. The log is the source of truth: every state change is appended, never updated in place. State is derived, not stored: reading the log and folding the entries reconstructs the current state, recomputable at any time. And the entry id is the cursor: monotonic, it is the resume position a reader saves, and — because the id carries time — a DateTime becomes a range bound, so the log can be read as of any past instant.

A Redis Stream is created the first time something is appended to it. XADD key * field value … appends an entry, assigning a time-ordered id of the form <milliseconds>-<sequence>; the * asks the server to mint the id, or an explicit id may be supplied. The entries form an ordered log: a later append always carries a larger id than an earlier one.

Reading is by range. XRANGE key - + returns every entry from the first (-) to the last (+) in id order; XRANGE key <start> <end> COUNT n reads a bounded slice. To rebuild state, a reader starts with an empty accumulator and applies each entry in order — the same fold every time, deterministic in the log.

An event is a fact that happened: it is never edited and never deleted as a correction (a correction is a new event). The log grows forward only. Because the entries never change, the fold over them is reproducible — replay the same log and get the same state. A bug in how state is derived is fixed by changing the fold and replaying; the events stay as they were recorded.

Use event sourcing when the history matters as much as the present: an audit trail, a feed of activity, a value that must be reconstructable as of a past time, or a state machine whose transitions other readers also consume. The log is the one authority, and multiple independent readers each fold it for their own view.

Avoid it when only the latest value matters and history is noise — a plain key holds the current value far more cheaply than a log that must be folded. A log also grows without bound unless retention is applied (the subject of R5.02); an unbounded log is a leak. And a fold over a long history is work — a snapshot of the folded state, taken periodically, bounds the replay a reader must do.

EchoMQ's bus carries a queue (work claimed and completed once) and, beside it, a Stream Tier: an append-only log many readers consume at their own pace. EchoMQ.Stream is the writer. EchoMQ.Stream.append(conn, queue, name, fields) mints an EVT-branded record id host-side, derives the explicit XADD id from it, and issues XADD emq:{q}:stream:<name> <xadd_id> id <branded> <fields…> — returning {:ok, branded}, the branded id as the receipt. The log is ordered by append the way the property store is ordered by mint: a strictly monotone writer makes the stream id, the entry order, and the mint order one and the same.

EchoMQ.Stream.read(conn, queue, name, from, to, count) wraps XRANGE and parses each entry back into a {branded, fields_map} tuple in mint order — the read side of the rebuild. The stream key emq:{q}:stream:<name> carries the per-queue {q} hash tag, so every key of one queue lands on one Valkey cluster slot.

Each dive takes one property of the log, in order: the append that makes it the source of truth, the read that folds it back to state, and the entry id read as the cursor and the time bound. Read them in order — the write first, the read second, the cursor third.