HN Showcase
Back to browse
GitHub Repository

High-performance message queue for Node.js — Valkey/Redis Streams with Rust-native NAPI bindings

81 starsTypeScript

I maintain Valkey GLIDE – built a Node queue doing 48k jobs/s

by anotherCodder·Feb 20, 2026·2 points·0 comments
Visit ProjectView on HN

AI Analysis

●●●BangerWizardrySolve My ProblemBig Brain

BullMQ replacement hitting 48k jobs/s via 1-RTT ops and Rust native bindings.

Strengths
  • •1-RTT architecture (completeAndFetchNext) eliminates chatty round-trips vs BullMQ's 3+ per job.
  • •Server Functions over EVAL scripts: persistent across restarts, no NOSCRIPT errors, cleaner ops.
  • •AZ-affinity routing and cloud-native design reduce cross-AZ latency and AWS egress costs by 75%.
Weaknesses
  • •Early-stage (0.4.3, 4 stars, no npm package published yet); adoption risk vs BullMQ's maturity.
  • •Requires Valkey/Redis 7.0+ with FUNCTION support; less compatible than BullMQ on older infrastructure.
Target Audience

Backend engineers building high-throughput systems on Node.js; teams already using Redis/Valkey at scale.

Similar To

BullMQ · RabbitMQ · Bull

Post Description

Hey HN,

I'm a maintainer of Valkey GLIDE (the official Valkey client) and work on the AWS ElastiCache team. Day job is deep in database client internals — which gives me a clear view of where Node.js job queues hit a ceiling at scale.

The problems with queues like BullMQ aren't subtle: 3+ round-trips per operation, Lua EVAL scripts that NOSCRIPT-error on restart, Lists/BRPOPLPUSH primitives that predate Streams, and complete blindness to cloud topology (cross-AZ bills sneak up on you).

So I built Glide-MQ. High-performance job queue for Node.js built on Valkey/Redis OSS Streams, powered by Valkey GLIDE — a Rust core exposed via native NAPI bindings.

Because I maintain the underlying client, I could go further than an external library ever could:

1-RTT per job — completeAndFetchNext folds completion + next fetch + activation into a single FCALL. No more chatty round-trips.

Server Functions over EVAL — one FUNCTION LOAD, persistent across restarts. NOSCRIPT errors gone entirely.

Streams + Consumer Groups from day one — replaced Lists/BRPOPLPUSH. The PEL gives at-least-once delivery with fewer moving parts.

Cluster-native, not cluster-bolted — hash-tagged keys from day one. No {braces} surprise when you scale out.

AZ-Affinity routing — reads go to same-AZ replicas. Up to 75% reduction in cross-AZ costs on ElastiCache.

Batch API pipelining — addBulk for 1,000 jobs: 228ms to 18ms (12.7x) via GLIDE's non-atomic pipeline.

IAM auth — native ElastiCache/MemoryDB auth with auto token refresh. No secrets in env vars.

Numbers (no-op processor, Valkey 8.0, single node): - c=1: 4,376 jobs/s | c=10: 15,504 jobs/s | c=50: 48,077 jobs/s - 15KB payload compressed to 331 bytes (98% savings)

Also included: transparent gzip (zero config), OpenTelemetry tracing, TestQueue/TestWorker in-memory backend for unit tests without running Valkey, and chain()/group()/chord() for job pipeline workflows.

Companion package: @glidemq/dashboard — drop createDashboard([q1, q2]) into any Express (or any other framework) app and get a live REST + SSE UI across all your queues (avifenesh/glidemq-dashboard on GitHub).

Would love brutal testing on it abilities — especially from anyone burned by queue scaling in production.

Similar Projects