Skip to main content

Design

Where ruststream-fred sits: between the RustStream runtime and the fred client, a client of its own per subscription, one shared pool.

The service, the RustStream runtime, this crate, the fred client and Redis, top to bottomYour serviceRustStream coreruststream-fredfred#[subscriber]handlersRustStream::new(..).with_broker(..)Runtime: dispatch, decode, settlementSubscribersof streams, listsand channelsPublishersof the samethree formsRedisStreamRedisListRedisPubSubPipeline windowof .pipeline()RedisBrokertopology, pool, credentialsA client of its ownper subscriptionPool4 connectionsRedis or Valkey: standalone, cluster or sentinel
The diagram as text
  1. Your service: #[subscriber] handlers; RustStream::new(..) .with_broker(..)
  2. RustStream core: Runtime: dispatch, decode, settlement
  3. ruststream-fred: Subscribers of streams, lists and channels; Publishers of the same three forms; RedisStream RedisList RedisPubSub; Pipeline window of .pipeline(); RedisBroker topology, pool, credentials
  4. fred: A client of its own per subscription; Pool 4 connections
  5. #[subscriber] handlers → Runtime: dispatch, decode, settlement: mounted
  6. Runtime: dispatch, decode, settlement → Subscribers of streams, lists and channels: polls
  7. Runtime: dispatch, decode, settlement → Publishers of the same three forms: publishes
  8. Subscribers of streams, lists and channels → A client of its own per subscription
  9. Publishers of the same three forms → Pool 4 connections
  10. A client of its own per subscription → Redis or Valkey: standalone, cluster or sentinel
  11. Pool 4 connections → Redis or Valkey: standalone, cluster or sentinel

The crate implements the core's broker traits over fred. The runtime above it is the same for every broker. Everything Redis-specific is in this crate: the descriptors of the three transports, what an acknowledgement means on each, where a retry copy goes, and the pipeline window.

A descriptor resolves once, at startup, against the connected broker, and yields a subscriber. The subscriber is a stream of deliveries that the runtime polls. The runtime decodes each delivery, runs the handler and settles the delivery with its outcome. A publish policy pairs with the connected broker into a publisher.

Each subscription reads on a client of its own, so a blocked read never holds up a publish. Publishes, settlements and the commands a handler sends share the pool. Lifecycle draws when each client opens and closes, and Path the way of one entry.

A stream entry carries the payload in a field named _payload and each header in a field h:<name>, so XADD and XREADGROUP keep both. A list entry and a channel message carry the headers in a frame around the payload: a binary frame, or a codec envelope when the descriptor names a codec.