Narad - The message broker that fits in one binary — and one head

@englhsrevz8oe Şengül — great question, and it's one I decided on purpose rather than by omission

Narad deliberately has no built-in retry engine, because retry policy is business logic: max attempts, backoff shape, which errors are retryable, where dead messages go — every team answers those differently, and a broker that hardcodes the answers becomes the thing you fight. What Narad gives you instead are three durable primitives — visibility leases, acks, and topics — that compose into every retry policy I know of, consumer-side, where you can see it and change it without a broker upgrade.

The full menu is documented here, and it's shorter than you'd expect: https://debanganthakuria.github.io/narad/client/handling-retries/ — a DLQ is literally just a topic you create (with the whole API available on it: alert on its depth, replay it, re-drive it after fixing the bug), bounded retries are a delivery_count field in your message envelope, and spaced backoff uses Narad's native delayed topics. The core pattern is ~10 lines of consumer code.

Your "reimplemented on every consumer side" concern is real though, and the honest answer to that isn't a broker feature — it's client SDKs. You can build one internally for your company that follows your specific retry methods.

If you try the patterns page and find a policy it can't express, tell me — that would genuinely change my mind about what belongs in the broker.

@hasboyac54710 Ayfer — you're describing what's already in the box

Every node serves Prometheus metrics on /metrics out of the box, zero config. Your exact list: queue depth is narad_consumer_lag_messages (per partition), ack rates come from the ack/nack/extend counters, and lag has two flavors — regular consumer lag plus narad_fanout_due_lag_seconds, which exists because offset-lag is a lying metric for delayed topics and I wanted the honest one.

And the repo ships a ready-to-import Grafana dashboard — ops/monitoring/grafana/ — 14 panels: throughput, consumer backlog, errors & rejections, disk, storage fsync latency, CPU/memory. It's not a marketing artifact; it's the actual dashboard I stared at for the 47-hour, 170M-message soak before cutting 1.0.

The Monitoring page also has a copy-paste alert table (the "wake me up" thresholds) and a section on what the dashboards look like during a node failure, so you know which spikes are normal: https://debanganthakuria.github.io/narad/operate/monitoring/

If you import it and something's missing for your setup, open an issue — this is exactly the feedback I want.