message queue · http queue · push delivery
Self-hosted HTTP message queue that pushes to your API
A message queue lets services talk asynchronously. betterMQ is built for the HTTP era: enqueue with a POST, receive work as a signed webhook.
What is an HTTP message queue?
Classic message queues assume consumers pull from a broker. An HTTP message queue flips that: your app enqueues jobs over REST, and the broker pushes an HTTP callback when it's time to run.
Producer → queue → consumer flow
| Role | betterMQ |
|---|---|
| Producer | Your API calls POST /v1/publish or POST /v1/enqueue |
| Queue | betterMQ stores the message durably with retries, DLQ, rate limits and priority |
| Consumer | Your endpoint receives a signed HTTP webhook — return 2xx to ack |
Message queue vs Kafka — when to use which
Kafka is an append-only event log for high-throughput streaming. betterMQ is a task queue for discrete jobs: send email, charge card, call a webhook, run a cron.
Full betterMQ vs Kafka comparison →
Why teams pick betterMQ over Redis queues
- · Single Rust binary — no Redis cluster, no separate worker processes
- · Push-only — consumers are plain HTTP endpoints
- · Built-in cron, delays, flow control, DLQ and signing
- · Self-hosted — payloads stay on your network
Common questions
- Is betterMQ a Kafka alternative?
- Not for streaming or log replay. It is a simpler message queue when your consumers are HTTP endpoints and jobs are tasks, not event streams.
- Is delivery at-least-once?
- Yes. Use idempotency keys and design handlers to be safe on retry — same as any production queue.
- Can I schedule messages?
- Yes — millisecond delays, UTC cron and fixed intervals are built in. Webhook scheduler guide.