3 ms·

Don't you solve at least half of this by putting a load balancer in front the service being hit (which is internal, so we control it), then the clients don't ne

Don't you solve at least half of this by putting a load balancer in front the service being hit (which is internal, so we control it), then the clients don't need to know which machines are up and working, you don't overload DNS packets with a bunch of endpoints, and the load balancer takes care of keeping track of which machines are available, and the clients don't need to share any state about the status of the individual remote machines. I'm not sure what this piece is getting at ("don't do this thing that no one would do anyway"), other than ignoring 20+ years of well-understood scaling methodology, and listing a bunch of unrelated gotchas (at high enough traffic rates, you have to deal with running out of ephemeral ports even without the design outlined). This isn't a great modern example of the compounding effects of bad design.

marcosdumay 6y ago
In-process caches of DNS replies would solve it (they don't have to last for long, 1 minute is enough). Doesn't libcurl do that by default? Federating the internal DNS would solve it. Who creates a DNS system without redundancy? A keeping the connections open for each process would solve it. But then, you'd need HTTP/1.1 or newer, maybe that's too new. In fact, that scenario requires breaking about every good practice for the tools used. Yet the author mainly blames the lack of threads. Yeah, sharing that coordination info would increase your scale by some 10x, while creating a lot of other unrelated failure modes.