TL;DR: I built Cue, a Raft-based distributed job queue that handles retries, dead-lettering, and durability without the operational overhead of Kafka or the manual plumbing of Redis. Single binary, zero external dependencies.
The Problem We All Know
You're building internal microservices. You need to dispatch background jobs — send emails, generate reports, process notifications. You need reliability: if a job fails, it should retry. If it keeps failing, you need to know about it.
I've been through this cycle multiple times. Each time, the available options felt like they required either too much operational overhead or too much custom code.
The Database Approach
Most teams start with a PostgreSQL table. It's familiar. But at some point, you need:
- Locking mechanisms
- Timeout handling
- Retry logic with backoff
- Cleanup jobs for stuck tasks
Suddenly, your application database becomes a bottleneck, and your job queue competes with your API traffic for resources.
Redis: Fast but Fragile
Redis pub/sub is blazing fast but has zero durability — if a consumer disconnects, messages are gone. Redis Streams improve durability but still require you to build retry and dead-letter handling yourself. Plus, you're now managing Redis persistence, which adds its own operational complexity.
Kafka: Powerful but Overkill
Kafka is optimized for high-throughput event streaming. It's battle-tested and capable. But if your only requirement is durable background jobs, you're paying for:
- Partition management
- Broker coordination
- Consumer group rebalancing
- ZooKeeper or KRaft
That's a lot of cognitive load for what should be a simple problem.
RabbitMQ: Mature but Another External Broker
RabbitMQ is a mature, excellent broker. But it's another external system with its own operational model, clustering, and management overhead.
What I Actually Wanted
A durable job queue with:
- ✅ Jobs that survive restarts
- ✅ Automatic retries with exponential backoff
- ✅ Dead letter queue for failed jobs
- ✅ Simple deployment and scaling
- ✅ No external dependencies
I didn't need infinite persistence or petabyte-scale throughput. I needed something honest about its limits and simple to operate.
Enter Cue
Cue is a distributed, in-memory job queue built around three core ideas:
1. Consistency Without Complexity
Cue uses the Raft consensus algorithm to keep all cluster nodes in sync. Every command is persisted to a Write-Ahead Log (WAL), so jobs survive restarts. If the leader crashes, a new one is elected automatically.
No ZooKeeper. No external coordination. Just a single binary.
2. Built-in Retry and Failure Handling
Automatic retries with exponential backoff are baked into the system, not an add-on. Failed jobs go to a dead letter queue with configurable retention policies. You don't write custom retry logic or cleanup scripts.
3. Simple Operations
All cluster nodes are identical. No special roles to configure. The system runs as a single binary with zero external dependencies.
The companion gateway, CueProxy, handles external communication — producers submit jobs via HTTP, consumers receive them over WebSockets. It's stateless and scales horizontally without coordination.
Cue won't replace Kafka, RabbitMQ, or Redis. Those tools solve different problems. If your primary requirement is reliable background job execution with automatic retries, dead-letter handling, and minimal operational overhead, Cue is worth evaluating.
Architecture Overview
Communication between cluster nodes uses QUIC with mandatory mTLS. Between proxies and the cluster, it's TLS-secured. Authentication and encryption without complex configuration.
What Cue Does and Doesn’t Guarantee
What Cue Guarantees:
- Durability: Jobs survive cluster-wide restarts (WAL persistence)
- At-least-once delivery: Duplicates are possible; idempotent consumers required for exactly-once
- Automatic retries: Exponential backoff with configurable limits
- Dead letter handling: Configurable retention for failed jobs
- Backpressure: Bounded queues with clear signaling
What Cue Doesn't Guarantee:
- Infinite queue size (in-memory, bounded by RAM)
- Historical replay of acknowledged jobs
- Exactly-once delivery without client idempotency
- Petabyte-scale throughput
Cue is designed for predictable, bounded workloads — not for replacing Kafka as a long-term event store.
Performance
The project includes cue-benchmark that measures two distinct phases:
- Ingestion: How fast the system accepts jobs (producer → proxy → cluster)
- Dispatch: How fast the system delivers jobs to consumers (cluster → proxy → consumer)
This isn't a synthetic micro-benchmark. It measures what you actually care about in production. You can run it in your own environment to understand throughput limits under your specific conditions.
Note: Early benchmarks show promising results, but performance characteristics depend heavily on your hardware, network, and workload patterns. I'd love community contributions to help optimize and validate performance across different environments.
What You'll Actually Use
Cue Cluster – The core distributed system that holds your jobs, handles retries, and maintains consistency via Raft.
CueProxy – The stateless gateway your applications talk to via HTTP and WebSockets. Handles authentication and passes jobs to the cluster.
cue-benchmark – A helper tool to test performance in your own environment (optional but useful).
Just two main pieces working together. No complex ecosystem to manage.
Community and Contribution
The code is open-source under Apache 2.0. If the design resonates with you, I'd love your feedback:
- 🐛 Open an issue for bugs or feature requests
- 💬 Challenge a design decision — I welcome constructive debate
- 📊 Benchmark it in your own environment and share results
- 📝 Improve the documentation
- 🔧 Submit a pull request
Early contributors have the opportunity to help shape where the project goes next. The architecture is flexible enough to evolve based on real-world needs.
Cue is still in its early stages. The core architecture is in place, but there’s plenty of room to improve performance, expand the ecosystem, strengthen testing, and refine the developer experience. If the design resonates with you, I’d love your feedback — whether that’s opening an issue, challenging a design decision, benchmarking it in your own environment, improving the documentation, or submitting a pull request. Early contributors have the opportunity to help shape where the project goes next.
Resources
- Main Project: github.com/m-javani/cue
- Gateway: github.com/m-javani/cue-proxy
- Benchmark: github.com/m-javani/cue-benchmark
- Documentation: m-javani.github.io/cue-docs
Top comments (0)