What delivery guarantee does ZeroQ provide?

At-most-once, best-effort. publish() resolves as soon as the message is handed to each connected WebRTC DataChannel, including when there are no peers, when the channel is congested, or when the payload exceeds the DataChannel message-size limit; in those cases the message is dropped. There is no visibility timeout, so a consumer that dies without acknowledging triggers no redelivery.

ZeroQ - Peer-to-Peer Message Queue for Browsers

WebSocket signaling server still required

Message bytes through a server

TCO Comparison

Stop paying for idle brokers

AWS SQS

$20K/yr

Complex IAM, region-locked, variable pricing based on requests.

ZeroQ

$0 broker

No broker to host: payloads flow peer-to-peer. A WebSocket signaling server is still required, and production use needs a BSL 1.1 licence — see Pricing below.

Confluent Kafka

$120K/yr

Heavy infrastructure, high baseline cost, overkill for most apps.

Architecture Patterns

Flexible messaging for any edge topology.

Publish / Subscribe

Decouple your producers and consumers seamlessly across client tabs, workers, and iframes.

Work Queue

Distribute resource-intensive tasks among multiple Web Workers. ZeroQ handles round-robin distribution automatically.

Fan-out Exchange

Broadcast messages to multiple independent queues simultaneously for parallel processing flows.

Live P2P Message Routing — Zero Servers

Direct from publishers to subscribers via intelligent edge routers.

Real-time Simulation

See ZeroQ in action locally.

Serialization Benchmark

Measures how fast JSON.stringify() runs in your browser. This is not a ZeroQ throughput figure — no peer connection is opened and no message is sent.

WebRTC DataChannel Stats (mock values — no peer connection is open)

Channel State: open

Buffered Amount: 0 bytes

Messages Sent: 0

Messages Received: 0

Topic Stream Console

Dead Letter Queue: 0 messages

Developer Experience

Clean, intuitive API inspired by standard queue interfaces.

import { ZeroQ } from 'https://cdn.jsdelivr.net/gh/itsoumya-d/zeroq@main/dist/index.mjs';

// A peer never receives its own publishes: the subscriber must be a different
// tab, worker or process pointed at the same signaling server and topicId.
const q = new ZeroQ({ discoveryUrl: 'wss://your-signaling-server/ws' });

await q.publish('orders', {
  id: 'ord_123',
  amount: 49.99,
  status: 'pending'
});
        

import { ZeroQ } from 'https://cdn.jsdelivr.net/gh/itsoumya-d/zeroq@main/dist/index.mjs';

const q = new ZeroQ({ discoveryUrl: 'wss://your-signaling-server/ws' });

// subscribe(topic, handler). The handler gets one argument: the envelope
// { id, topic, payload, timestamp, seq, priority?, retryCount }.
const sub = await q.subscribe('orders', (msg) => {
  console.log('Received order:', msg.payload.id);
  processOrder(msg.payload);
});

// Work queues use consume(queue, handler) and give you ack/nack:
await q.consume('orders', (msg, ack, nack) => {
  try { processOrder(msg.payload); ack(); } catch { nack(); }
});
        

// There is no deadLetterExchange option and no maxRetries option.
// nack() increments retryCount and re-broadcasts, up to 3 attempts; after
// that the message stays in the local IndexedDB store as a dead letter.
await q.consume('orders', (msg, ack, nack) => {
  if (msg.retryCount >= 2) { sendToOpsDashboard(msg); ack(); return; }
  try { processOrder(msg.payload); ack(); } catch { nack(); }
});

// NOTE: retries are re-broadcast, so only a DIFFERENT peer that also
// consumes this queue can pick them up. There is no public accessor for
// the dead-letter store; open the 'zeroq-db' IndexedDB database directly.
        

// Persistence and WebRTC transport are always on; there are no storage or
// sync options. The full option set is:
const q = new ZeroQ({
  discoveryUrl: 'wss://your-signaling-server/ws',  // default 'ws://localhost:8080'
  topicId:      'orders-room',                     // signaling room; peers must share it
  licenseKey:   'BSL11-...',                       // commercial licence key
  allowEval:    true                              // silence the commercial-use notice
});

// Messages are written to the local 'zeroq-db' IndexedDB store, so they
// survive a reload in that browser. They are NOT replayed to peers that
// were offline, and there is no retention policy or TTL.
        

Enterprise Grade. Zero Servers.

⚡

P2P Sync

Messages flow directly between clients via WebRTC. No central broker bottlenecks.

💀

DLQ Support

Built-in Dead Letter Queues catch failed messages automatically after max retries.

💾

Persistent Storage

Backed by IndexedDB to survive page reloads and browser restarts flawlessly.

🌊

Backpressure

When a DataChannel's bufferedAmount exceeds 64 KB the message is dropped and a message_dropped event is emitted. Producers are not paused and nothing is re-queued.

⭐

Priority Queues

enqueue() carries a priority value on the message envelope for consumers to read. It does not reorder delivery — there is no priority scheduler.

🔄

Multi-topic Routing

Any number of named topics and queues on one mesh. Names are matched exactly — there is no wildcard or pattern matching, and topics and queues share a single namespace.

Frequently Asked Questions

Is ZeroQ a free alternative to Kafka?

No. ZeroQ is source-available under the Business Source License 1.1 and any production use requires a paid commercial licence; it is free only for personal evaluation, academic research and contributing pull requests. It is also not functionally equivalent to Kafka — delivery is at-most-once, with no durable log, no replay and no consumer offsets. It removes the need to operate a broker for small-scale browser-to-browser fan-out, but a WebSocket signaling server is still required.

How does it persist messages without a server?

Each peer writes messages it publishes or receives to its own IndexedDB store (zeroq-db), so they survive a reload in that browser. There is no replication and no cross-peer consensus: a peer that is offline when a message is broadcast never receives it, and there is no retention policy, so the store grows until the browser's storage quota is reached.

Simple Licensing

Licensed under BSL 1.1. Free for most, reasonable for enterprise.

Indie / Startup

$299 / license

Unlimited local queues
Community Support
Standard P2P Features

Pro

$1,999 / license

Advanced Routing
Priority Queues
Email Support

Enterprise

$9,999 / license

Custom SLA
Dedicated Account Manager
Custom Connectors

Message queues without Kafka.Without servers.