My professional interests are cloud and big data technologies, machine learning, and software development. I like to read source code and research papers to understand how stuff works.
Pronoun: He
Thanks for the comment! I agree with you that the solution is certainly not meant to work in a distributed system. The focus was more about how you can reduce the amount of possible state, especially by avoiding invalid state. I believe that this is true for both local and distributed systems.
In order to avoid conflicts with concurrent access you can use locking. In this case I believe that optimistic locking would be a good fit as it is probably not so likely to have a conflict when updating. In case you do, you'd have to retry.
If you need to synchronize replicas of this data structure you can store the data in a distributed data store that has mechanism to find consensus. Raft, e.g., is a very simple consensus algorithm that would allow you to have many replicas of the data but still be consistent.
Did I understand what you were refering to? How would you implement the solution using CRDTs?
Locking is fine in a single instance of an application but doesn't help in a distributed system where availability is the priority over consistency of data.
My professional interests are cloud and big data technologies, machine learning, and software development. I like to read source code and research papers to understand how stuff works.
Pronoun: He
I agree. You have to understand whether you want availability or consistency if there is a network partition. Based on your requirements you should select the coordination algorithm that fits your needs.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Thanks for the comment! I agree with you that the solution is certainly not meant to work in a distributed system. The focus was more about how you can reduce the amount of possible state, especially by avoiding invalid state. I believe that this is true for both local and distributed systems.
In order to avoid conflicts with concurrent access you can use locking. In this case I believe that optimistic locking would be a good fit as it is probably not so likely to have a conflict when updating. In case you do, you'd have to retry.
If you need to synchronize replicas of this data structure you can store the data in a distributed data store that has mechanism to find consensus. Raft, e.g., is a very simple consensus algorithm that would allow you to have many replicas of the data but still be consistent.
Did I understand what you were refering to? How would you implement the solution using CRDTs?
Locking is fine in a single instance of an application but doesn't help in a distributed system where availability is the priority over consistency of data.
I agree. You have to understand whether you want availability or consistency if there is a network partition. Based on your requirements you should select the coordination algorithm that fits your needs.