If you’ve ever spent a weekend wrestling with Redis cluster configs, only to have your job queue fall over on a Monday morning — you’re not alone. That sinking feeling when you realize your distributed masterpiece just became your operational nightmare is the universal trauma of scaling engineering teams.
The most dangerous phrase in software engineering is ‘we need distributed infrastructure.’ Because nine times out of ten, what you actually need is a single binary that just works.
Enter Zizq. A job queue so stripped down it makes traditional architectures look like a cry for help. Built on a LSM-tree database (fjall) and lock-free skip lists, it’s durable, crash-resistant, and — here’s the kicker — requires zero external dependencies. No Redis. No Kafka. No sidecar. Just zizq.
I’ve been quietly building this since March. It’s not a hobby project; it’s a reaction to years of operational pain. The kind of pain that makes you ask: why do we need a distributed queue when 90% of our jobs are just ‘run this, then run that’?
And the industry’s answer? ‘Because scale.’ But scale is a lie we tell ourselves to justify complexity. The truth is, most teams never hit that scale. They just pay the tax of over-engineering anyway.
Zizq challenges that assumption head-on. It supports FIFO, backoff, retry, cron scheduling, job batching, and even jq-expression payload filtering — all in a single binary. It’s language-agnostic via HTTP API, with official clients for Ruby, Node, and Rust. You can even run zizq top to see everything in a terminal UI.
Simplicity is not a feature. It’s a survival strategy. And Zizq proves that you don’t need a PhD in distributed systems to process background jobs reliably.
One Hacker News user put it best: ‘Don’t need it today, but love the spirit of open source, following & starred!’ That’s the reaction of someone who’s been burned by complexity and recognizes a lifeline when they see one.
Here’s the twist: What if the future of job queues isn’t more distributed, but less? What if we’ve been scaling for the wrong problem? Zizq isn’t just a tool — it’s a signal that the industry is finally waking up to the cost of over-architecting.
You don’t need Redis for job queues. You need a single binary that fits into any stack, runs anywhere, and doesn’t require a manual to operate. That’s Zizq.
Next time someone tells you to add a distributed queue, ask yourself: do I really need this, or is there a better way? The answer might be simpler than you think.
FAQ
Q: Is Zizq production-ready for high-throughput workloads?
A: It's built on a LSM-tree database with lock-free skip lists, designed for durability and crash recovery. It's not targeting Redis-level throughput, but for the vast majority of use cases (thousands of jobs per second, single-node), it's more than capable. The trade-off is simplicity and zero operational overhead.
Q: What's the practical implication for an engineering team?
A: You can replace a Redis cluster, Sidekiq, or similar stack with a single binary. No configuration management, no network dependencies, no cluster maintenance. Setup takes minutes instead of hours. This dramatically reduces onboarding time and operational burden for async processing.
Q: Isn't a single-binary queue a step backward in terms of scalability?
A: Tell that to the millions of teams that never outgrow a single machine. Horizontal scaling is a feature — not a requirement. If your job queue needs to handle 10,000 jobs per second across multiple nodes, Zizq isn't for you. But if you're like most teams, you're paying for capacity you don't use. Going back to a single binary is not backward — it's a correction.