Michael de Silva's Blog

Software Engineer. Rubyist and Roboticist.

Michael de Silva's Blog

Software Engineer. Rubyist and Roboticist.

CAP and Concurrency with Multiple Worker Processes

Anyone who's played with distributed systems knows the kind of pain one would end up with. There's mutex/transaction locking, pessimistic locking, and then there's the joy of dealing with multiple concurrent workers, running jobs asynchronously

Having played with Searchkick I stumbled on an interesting discussiong on race conditions which ultimately led me to 'Preventing Race Conditions With Fencing Tokens In Rails'.

And if you haven't heard of it before, this falls under CAP theorem.

Thankfully a friend of mine was to the rescue regarding a particular usecase of mine with,

Multiple workers can't get into a split-brain if they're all talking to the same storage cluster that's in control of reads/writes

None of this is relevant if you have a single database node... a single node is trivially CP in CAP terms

comments powered by Disqus