I'm a beginner at distributed systems but I am curious many solutions seem in common with multithreaded systems: "sharding" which is to avoid coordination allows embarrassingly parallel scaling.
Time is the thing that we don't have enough of at request time because a round trip takes years in computer time. (See "latency numbers every programmer should know")
It seems contention is the critical factor: if I have a database key and I want to scale concurrent access to it, we are contended on that key to see if other users are writing conflicting changes to the same key, such as MVCC.
Optimistic - assume no contention (and handle it when it happens)
Pessimistic - assume lots of contention (prepare to handle it before it happens)
Even a naive sharded approach requires coordination if you want a scalable solution. Where do you send keys when there are 4 shard buckets? What happens when we want 5, or 8, or 32 shard groups? Just yolo turn off all writes, toggle some config and turn everything back on? Not great. You've changed the shard selection of a key from 2 to 11? What happens to all the previously persisted keys that were written to 2? The answer is unsurprisingly complicated, and depending on the system you're writing, this can be a really hard to solve against if you haven't prepared to grow (or shrink).
As you noted, there are a lot of similarities between parallel programming and distributed computing.
The coordination of shared resources is the key problem in both fields. Distributed computing is more complex since you're adding in the concept of communication which may be unreliable.
Yes,distributed systems problems and multi threading problems tend to have very similar solutions. Contention is the critical factor indeed - if there's no coordination needed, then we can keep scaling forever.
I think by "something is wrong" you mean that data has changed and if data hasn't changed then the coordinating method of a distributed system isn't very relevant
Time is the thing that we don't have enough of at request time because a round trip takes years in computer time. (See "latency numbers every programmer should know")
It seems contention is the critical factor: if I have a database key and I want to scale concurrent access to it, we are contended on that key to see if other users are writing conflicting changes to the same key, such as MVCC.
Optimistic - assume no contention (and handle it when it happens)
Pessimistic - assume lots of contention (prepare to handle it before it happens)