Not trying to be snarly, but you should read the article and come back to discuss. This specific point is adressdd.

It needs a single consumer to be that simple.

And a single producer! i.e. it breaks down if you add support for fault tolerance

TCP is a one to one relation, distributed systems are many to many.

I'd tell you a joke about UDP, but you might not get it.

More seriously, you are confident and very incorrect on your understanding of distributed systems. The easiest lift, you can fix being very incorrect (or at least appearing that way) by simply changing your statements to questions.

Personally, I recommend studying. Start with the two generals problem. Read Designing Data Intensive Applications; it is a great intro into real problems and real solutions. Very smart and very experienced people think there is something to distributed systems. They might be on to something.

UDP gives you practically no guarantees about anything. Forget exactly once processing, UDP doesn't even give you any kind of guarantees about delivery to begin with, whether delivery will happen at all, order of delivery, lack of duplicates, etc, nothing. These things are so far from comparable that this idea makes no sense even after trying real hard to steelman it.

UDP plus increment means that the client can request a snapshot to be re-sent. This mechanism is used in financial exchanges and works amazing.

This illustrates that the webdevs who write articles on "distributed system" don't really understand what is already out there. These are all solved problems.

You are 100% correct. UDP can be used to solve this problem, in fact, UDP can be used to solve any (software) networking problem, because its kind of what networking is.

The thing that webdevs want to solve is related but different, and whether the forest is missed for the trees is sometimes hard to tell.

What webdevs want to solve is data replication in a distributed system of transactions where availability is guaranteed, performance is evaluated horizontally, change is frequent and easy, barrier to entry is low, tooling is widely available, tech is heterogeneous, and the domain is complex relational objects.

Those requirements give you a different set of tradeoffs vs financial exchanges, which despite having their own enormous challenges, certainly have different goals to the above.

So does that mean this article is a good solution to the problem? I'm not sure, its hard to tell sometimes whether all the distributed aircastles invented for web-dev really pay out vs just having a tightly integrated low-level solution, but regardless of the hypothetical optimum, its hard to argue that the proposed solution is probably a good fit for the web dev culture vs UDP, which unfortunately is something very important to take into account if you want to get stuff done.

> in a distributed system of transactions where availability is guaranteed, performance is evaluated horizontally, change is frequent and easy,

Isn't that the situation inside a CPU across its multiple cores? Data is replicated (into caches) in a distributed system of transactions, because each core uses its own L2 cache with which it interacts, and has to be sent back to main memory for consistence.

Or perhaps you've simply not learned the basics of actual distributed systems literature, and so are ignorant of the limitations of those solutions?

UDP doesn’t guarantee exactly once processing.

See my response to your sibling.