வரிசை · queue, row, order

Ordering and parallelism from the message key — not a partition count you guessed

Varisai is a durable message log with per-message delivery tracking. Messages with the same key arrive strictly in order; different keys never wait for each other. Set key = tenant_id and a noisy neighbour becomes structurally impossible.

Open the dashboardRead the API docs
# publish — the key is the whole model
curl -X POST localhost:7700/v1/streams/orders/messages \
-d '{"key":"tenant_42", "payload":{"order_id":8891}, "deliver_at":"2026-09-01T10:00:00Z"}'
 
# consume — retries, backoff, and DLQ are declared, not coded
const stop = varisai.consume("billing", async (message) => {
await chargeCustomer(message.payload); // throw = retry, resolve = ack
});

The features every team rebuilds, built in

Kafka is a log without per-message delivery. RabbitMQ delivers but forgets. Teams bolt Postgres and Redis alongside either to fill the gap — Varisai is that gap, as one system.

Per-key lanes
Strict FIFO per key with unbounded parallelism across keys. A stuck key parks its own lane and blocks nothing else — head-of-line blocking is gone by construction.
Declared retries & DLQ
Max attempts, exponential backoff with jitter, per-attempt leases, and a browsable dead-letter queue with one-click redrive — configured on the subscription, not coded in every consumer.
Scheduled delivery
Publish with deliver_at and the message stays invisible until that instant — durable, cancellable until it fires, and visible on its own dashboard screen.
Trace any message
"Why hasn't this been processed?" is one paste away: every attempt, consumer, duration, and error — and if it's blocked, the exact message blocking it, by ID.
Replay one tenant
Acking never deletes. Seek any subscription to an offset or timestamp — optionally for a single key — and replay one tenant's history without touching anyone else's.
An operational UI
Not a stats dashboard — a tool. Diagnose a stuck consumer, skip a poison message, redrive a failure group, and pause a lane without leaving the browser.

The key model in thirty seconds

Every message carries a key. That single field replaces partitions, queues, and sharding decisions.

Same key
  • Delivered strictly in publish order, one at a time per subscription.
  • A failing message parks its lane; everything behind it waits — as it should.
  • Effective serial pipeline when you want one: use one key.
Different keys
  • Fully independent: no shared cursor, no shared failure.
  • Parallelism = number of active keys, not a config value.
  • A million keys and a thousand consumers is the same object as one key.

Two scenarios, one primitive

Everything below is a single feature — the message key decides what waits and what runs in parallel. Both animations loop through a real failure.

Ticket booking — first come, first served

Five buyers, four tickets, key = event_id: one lane, one buyer processed at a time — overselling is impossible by construction. When P1's reservation keeps failing, the retry policy backs off while P2–P5 hold their exact places; after max attempts P1 dead-letters, the lane resumes, and the remaining four tickets sell in arrival order.

tickets left: 4tickets left: 3tickets left: 2tickets left: 1sold outorders · key = event-42 · strict FIFOP1P2P3P4P5booking workerone at a time per eventfailed messages (DLQ)P1 keeps failing — retries back off while P2–P5 wait, in orderP1 dead-letters after max attempts — the lane resumes, all 4 tickets sell
key = event_idretry: exponential, then DLQdeliver_at = hold expiry

Ride matching — dispatch without double-booking

Ten riders, five drivers, two keys. key = zone queues riders first-come-first-served; key = driver_id means a driver can never hold two offers at once. When every driver is busy, C6 waits at the head of the lane — retrying, never losing their place — and takes the first driver who frees up, before C7. Runnable in examples/ride-matching.

ride-requests · key = zone-1 · strict FIFOC1C2C3C4C5C6C7C8C9C10zone matcherone ride at a timeD1driver laneD2driver laneD3driver laneD4driver laneD5driver lanefree!riders match in arrival order — one driver each, never two offers to one driverall five drivers busy — C6 waits at the head, retrying, keeping their placeD2 finishes a trip — C6 matches before C7. FCFS, enforced by the lane
key = zone → rider FCFSkey = driver_id → one offer in flightnack + retry = waiting for a cab

Honest guarantees

What is promised is enforced. What is not promised is written down.

Guaranteed
  • Durability: publishes acknowledged with majority writes.
  • Strict FIFO per (stream, key, subscription).
  • At-least-once delivery until acked, dead-lettered, or expired.
  • Retention independent of acking; replay by offset, time, or key.
  • Scheduled delivery that survives restarts.
Not guaranteed
  • No exactly-once — consumers must tolerate a repeat. Dedup narrows the window; it cannot close it.
  • No ordering across different keys.
  • No cross-stream transactions.
  • Scheduled delivery is "at or after", not "exactly at".

Self-hosted in one command

Web tier, worker, and MongoDB replica set — one docker compose up. Cognito sign-in, scoped API tokens, Prometheus metrics, and TLS overlay included.

Create an accountRead the 5-minute guide

Not ready yet? Get an email when new releases land.