A self-hosted message broker: a durable message log with per-message delivery tracking, where ordering and parallelism are governed by the message key rather than by a partition count chosen in advance. Same key = strict order, one at a time; different keys never wait for each other. Retries, backoff, dead-lettering, scheduled delivery, and tracing are declared on the subscription, not coded in every consumer.
Kafka orders within a partition, and you choose the partition count up front — it caps parallelism and is painful to change. Kafka also has no per-message delivery state: no built-in retries, no DLQ, no scheduled delivery, and one bad message can block a whole partition. In Varisai the ordering unit is the key: parallelism = active keys, a failing message parks only its own lane, and retries/DLQ/scheduling are broker-side. See the full comparison.
SQS FIFO's message groups are the closest model, but SQS FIFO caps throughput, offers no browsing or replay (messages are gone once consumed), delays cap at 15 minutes, and there is no per-message trace. Varisai keeps the log after acking — replay any subscription, even a single key, by offset or timestamp — schedules arbitrarily far ahead, and runs on your own MongoDB.
No. There are no partitions. Every message carries a key, and the key is the unit of ordering and parallelism. A stream with a million keys and a thousand consumers is the same object as a stream with one key — nothing to size, resize, or rebalance.
Deliveries are leased. Ack and the lane moves on; crash or hang and the lease expires, the attempt counts as failed, and the message is redelivered per the subscription's retry policy. Nothing is lost, and other keys keep flowing the whole time.
The declared retry policy takes over: max attempts, backoff with optional jitter. While a message retries, its lane is parked — later messages on that key wait, as ordering demands — but every other key is unaffected. After max attempts it dead-letters into a browsable DLQ grouped by error signature, and the lane resumes. Redrive in bulk, by error group, or individually.
No — delivery is at-least-once, so consumers must tolerate a repeat. Publish-side dedup via idempotency_key narrows the window (default 24h) but cannot close it. No broker can honestly promise exactly-once side effects.
Node.js and MongoDB. One docker compose up starts the web tier, a worker, and a single-node MongoDB replica set — or point MONGODB_URI at Atlas or any replica set. Publishes are acknowledged with majority writes; consumers are woken push-style via change streams.
Acking never deletes — retention does (per stream, time-based). Seek any subscription to an offset or timestamp, optionally scoped to one key, and deliveries from that point become pending again. Replay one tenant's history without touching anyone else's.
Source-available under the Elastic License 2.0: use it freely, self-host it in production, modify and redistribute it. The one restriction: you cannot offer Varisai itself to third parties as a hosted or managed service.