Guides & Recipes

topics ships five concepts — Topic, Record, seq, Router, Tombstone — plus a permanent delete operation, and a small /v0 HTTP surface. These guides show how those primitives compose into the messaging patterns you actually deploy: a job queue, pub/sub fan-out, a durable replayable stream, and N-way multi-master mirroring. Each is a recipe — copy the curl, adapt the config, ship it.

The point of this section: topics is not four products. It is one append-only log, made durable per topic, with server-side fan-out and an explicit gap signal. The “patterns” are just configuration choices on that one substrate.

The substrate, in one paragraph

A topic is a named append-only log. You POST records into it and read them back from a from_seq cursor with /diff, or live over SSE watch. What turns a plain topic into a queue, a pub/sub feed, or a durable stream is config: the durability class (ephemeral / memory / disk / fsync), the retention caps (cap_records / cap_bytes / ttl_ms), the full-topic policy (discard: "old" vs "reject"), and whether it is a lease queue (type: "queue"). Routers copy one topic’s records into another, at-least-once and per-source FIFO, preserving the origin $node so loop-prevention makes mirroring echo-free.

Which guide do I need?

• Many producers, many workers, work must not be lost, each job processed once-ish. You want a Job Queue — either a cursor queue (Bull-style) or a lease queue.
• One publisher, many subscribers, low latency, bounded memory, gaps tolerable. You want Pub/Sub.
• A consumer must be able to replay from any point, and must never silently miss a record. You want a Durable Stream.
• Several symmetric nodes that each write and each consume the union, without echo. You want Multi-Master Fan-out.

The four recipes