I'm glad you said this. There's an async cargo cult going on, where every service must be written in "performant" async code, without knowing the actual resource and load requirements of an application.
From the last benchmark I ran [1] async IO was insignificantly faster than thread-per-connection blocking IO in terms of latency, and marginally faster only after we hit a large number of clients.
Async IO doesn't necessarily make your code faster, it just makes it difficult to read.
> OS-level multitasking won't be able to achieve the same level of concurrency
Do you have a source for this claim? I've seen it repeated many times, especially in the node.js community but I've yet to see any evidence to back it up. From what I've read, a synchronous threaded model can be just as fast as an event-based system [1].
It can be either TCP or UDP. Regardless, UDP has a checksum as well.
The likelihood of a bit-flip is very uncommon. Even taking into account the volume of computers out there, the likelihood of a bit-flip at the exact spot (in the domain name) and moment of a DNS lookup (before the checksum is calculated) is astronomically uncommon. This article is garbage.
[1] https://en.wikipedia.org/wiki/Dead_mall#Changes_in_the_retai...