# Simulator: Try bunqueue in Your Browser

Try bunqueue live in your browser: jobs flowing through priorities, retries with backoff, dead letter queues, sharding and worker concurrency.

Canonical: https://bunqueue.dev/simulator/

---

import Simulator from '../../components/simulator/Simulator.tsx';

<div class="bq-wrap bq-hero">
  <span class="bq-eyebrow">simulator</span>
  <h1 class="bq-hero-h1 bq-bench-h1">The engine, <em>in your browser.</em></h1>
  <p class="bq-hero-sub">A faithful in-browser model of bunqueue's memory/SQLite engine. Push jobs and watch its lifecycle, waiting to active to completed, with failures bouncing through delayed backoff until they land in the dead-letter lane.</p>
</div>

Use the **scenario chips** for one-click demos, or drive everything by hand from the control panel. The transport bar pauses the simulation clock and runs it up to 4× speed. It mirrors the FNV-1a shard mapping, priority ordering, and controls of the memory/SQLite engine; PostgreSQL uses database ordering and locks instead of in-memory delivery shards.

<Simulator client:load />

## What you're looking at

- **Pipeline**: every job as a chip in its state lane. Active chips show live progress; retry chips carry their attempt count (`↻ 2/3`) and backoff countdown; dead letters show the failure reason.
- **Shards**: bunqueue maps each queue to a shard with `fnv1aHash(queueName) & SHARD_MASK`. A cell flashes when a push lands on it. All jobs of one queue always share one shard.
- **Throughput**: completions per second over the last 60 seconds of simulation time.
- **Workers**: each card is one worker; the dots are its concurrency slots (filled = busy). Stopping a worker lets in-flight jobs finish first.
- **Events**: the server log tail: pushes, completions, retries, dead letters, and every control action.

## Scenarios to try

1. **Burst of 80**: bulk-push 80 jobs and watch four worker slots chew through the backlog.
2. **Priorities win**: P9 jobs pushed *after* a P1 backlog still jump the whole line.
3. **Scheduled jobs**: delayed jobs wait in their lane until the countdown expires.
4. **Failure storm**: at 55% failure rate, retries back off exponentially (1.2s → 2.4s → DLQ). Hit **Retry DLQ** to give dead letters a fresh attempt budget.
5. **Rate limited**: eight worker slots, but the queue releases only 4 jobs/sec: backpressure you can see.

Then compose your own: pause a queue mid-burst, drain it, or crank the failure rate while a scenario runs, effects stack like they would on a real server.

## How it maps to real bunqueue

| Mechanic | Simulator | Real bunqueue |
|----------|-----------|---------------|
| Shard mapping | `fnv1aHash(queue) & 7`, 8 shards | Memory/SQLite: same hash with an auto-detected shard count; PostgreSQL: database row ordering/locks |
| Priority order | Higher first, FIFO within a priority (4-ary min-heap) | Same |
| Retries | Exponential backoff, DLQ after 3 attempts | Configurable `attempts`/`backoff` per job |
| Rate limit | Token bucket, jobs/sec per queue | [`RateLimit`](/guide/rate-limiting/) command |
| Storage | In-memory, resets on reload | Memory/SQLite, or authoritative PostgreSQL for multi-broker servers |
| Workers | Simulated processing time (0.45–1.5s; the priority demo uses a slower 1.1–2s worker) | Your code, over TCP or [embedded](/guide/quickstart/) |

Ready for the real thing? Start with the [quick start](/guide/quickstart/), then meet the [Queue](/guide/queue/) and [Worker](/guide/worker/) APIs.