> We have DNS, we don't need log sender to have a service discovery mechanism on top of that. Having service discovery solves some issues. * DNS TTL and appli

> We have DNS, we don't need log sender to have a service discovery mechanism on top of that. Having service discovery solves some issues. * DNS TTL and applications holding on to DNS names indefinitely (prometheus, haproxy, nginx, and I bet your app somewhere all do this). * Applications that don't support DNS record priorities. * Serving different results to different clients based on their identity that isn't isn't random. > Log processor doesn't need a fucking queue. Log sender does, for network reliability one Yes. That's what the queue is for. The log sender also has a queue but as it lives on the host itself minimizing its use is how you don't lose logs on server crashes. If your architecture is the log processor accepts logs, and stores them in a queue for buffering then you've implemented the same architecture. But if that queue lives on the log processor itself then you risk data loss if that server dies. Having a shared queue in front of the pool of log processors, is simpler, has better throughput, easier to shard, and more reliable. Logs can't get stuck on a particular processor anymore because its lease will end and another worker will pick it up.