By ngaut - 11 hours ago
Showing first level comment(s)
jdormit - a minute ago
It doesn't provide any tools for idempotent calculations yet, just at-least-once delivery guarantees. But when you use it as a framework you get the benefit of all the configurable processors in your new service.
jeffail - 6 hours ago
I gave a quick intro to nsq talk at our local go meetup recently. If you haven't used NSQ before I highly recommend giving it a try.
gbrayut - 6 hours ago
I'm in the process of rejigging our live telemetry pipeline (dealing with petabytes) to improve flexibility and resiliency and have been looking for something to replace our similar systems that have grown organically. This fits the bill exactly; it's designed exactly how I imagined our new system should look.
I'm wondering if HN has their personal favorite for these sorts of problems.
devbug - 7 hours ago
ngaut - 9 hours ago
We have 100's of tenants, each of which could get their own stream with some delivery guarantees set. If one tenant's endpoint is down or another tenant fills the stream with 1M messages, it should not affect delivery rates of other tenants. Seems to fit the bill.
I see the HTTP output mentions some retries, but I guess these run as part of the delivery step, blocking this goroutine as opposed to rescheduling the message? Sometimes it takes hours for clients to restore their receiving systems and it would be great if messages for past N hours would still be delivered..
clon - 4 hours ago
xer0x - 6 hours ago
guywhocodes - 6 hours ago
kanwisher - 8 hours ago
packetized - 6 hours ago