Rethinking webhook/event transports: Redis, NATS, Kafka, cloud…

[pobk]

Hello all,

Webhooks are good. I like webhooks because I can get events out of NetBox when they happen, not by polling for changes.

Right now NetBox can fire off webhooks over HTTP and it uses Redis for the event queue. I think everyone will agree it works well, but it feels a bit locked in compared to how data sources are handled. With data sources, you can pick local fileystem, Git or S3, all behind the same abstraction.

What if webhooks and events worked the same way? Instead of being tied to HTTP+Redis, NetBox could expose a pluggable transport layer. That would let operators choose the backend that fits their environment, whether that's:

• HTTP callbacks (as we have today)
• Message queues like Kafka, NATS, or RabbitMQ
• Cloud native services like Amazon SNS/SQS, Google Pub/Sub, or Azure Service Bus
• Other options down the line

One strong motivation for this is flexibility around dependencies and licensing. Redis' license change (and the move towards Valkey) has forced many projects to rework parts of their stacks. This is a clear risk to being tied to a single upstream dependency. Even when alternative backends exist, they may not always speak the same wire protocol. Redis and Valkey are keeping protocol-level compatibility (for now), but how long is that likely to last?

The evidence for Redis/Valkey divergence is already starting to cause drift:

• AWS (via ElastiCache) documents that Valkey 7.2.6 has compatibility differences to Redis OSS 7.2.4 in certain behaviors (e.g. freeze time sampling, error codes for blocked streams).
• Argo CD (a major CNCF project) has explicitly debated replacing Redis with Valkey in its architecture due to licensing concerns.
• Arch Linux is replacing its Redis package with Valkey in its repos in response to the license change.

As for transports, NATS is one option I've been testing. It's lightweight, secure, and already common in the automation space. gNMIC uses it for streaming-telementry clusters. NATS also has extras like streams, key/value, and work queues that overlap with some of Redis' functionality. But the bigger idea is not about one backend, it's about choice.

Questions to the group:

• Is HTTP+Redis/Valkey already enough for most use cases?
• Would a pluggable transport layer add real value?
• Which transports would actually get used in practice if this existed?