Pick Your Distributed Poison
hazelweakly.me
hazelweakly.me
As an aside, I’ve never enjoyed the defeatist culture that permeated operations and distributed systems pop culture, which this post seems to re-enforce.
Does it really matter wherever is bad or not? As far as I know, every database that scales beyond a single node (for performance) is eventually consistent. Otherwise you've gotta wait for a sync between nodes before a response can be given, which would effectively force your cluster to have worse performance then running on single node again.
That's SO not true. Spanner, Amazon's S3 are some of the biggest databases on the planet, and they are strongly consistent.
> Otherwise you've gotta wait for a sync between nodes before a response can be given, which would effectively force your cluster to have worse performance then running on single node again.
Yes, you are trading latency for fault-tolerance, but so what? What if the resulting latency is still more than good enough? There is no shortage of real large-scale applications where this is the case.
This is novel yet obvious in retrospect, has it been articulated or surveyed elsewhere?
If you have a vector clock with snapshot reads, then you may not know consistently what the system looks like now, but you can know what it looked like as of some arbitrary previous point in time. If your use case doesn't require read-modify-writes (e.g., metric calculations where the source of truth is out of your control and you just need to aggregate deltas), then that's good enough - you can find a set of results that are in sync with each other, even if they're not fully up to date.
If you have limited read-modify-writes, but you can at least engineer synchronous transactions on subsets of the data (e.g., single-row-level transactions) with asynchronous replication and fan-out of side-effects, then you can turn more complex problems into something that looks like the first case.
Those tricks alone are enough to remove most of the weirdness with eventual-consistency, but the broader point is that distributed system design is more about learning a toolbox of tricks to handle and describe certain patterns, of which you may have any number in any combination in any given project, than it is about "solving" the problem once and for all.
For my corporate customers, what you are describing is way too sophisticated. They do what others do. As Kafka is de facto messaging platform, everybody uses it.
For example, if source data is multiplexed via Kafka into one sink, people typically say that the sink is "eventually consistent". Another case is when an operation writes into multiple microservices without transactions. People are not even consistent in their speech, let alone how they handle their data.
It seems to me that in 99% of such corporate systems would work better if people would optimize integrity (i.e. communicate with real transactions on a real database) instead of optimizing for performance and scalability.
I think the author just wanted to write a glib little blog post.
But I don't really think the allusive writing style is a good fit for tech. Actually it's pretty annoying even with non tech. YMMV. Here, it's hard to understand the post without already knowing most of what it's saying.
Of course, it's a blog post, the author doesn't owe anyone anything.
Here[1] is an example of what rigorous reasoning about distributed systems looks like.
the non-deterministic algorithm emerges when, abstracting from their mutual differences, we concentrate on what the many algorithms of the class have in common.