Leader election and distributed locking reduce to the same problem… which is proven to be impossible. It means in some edge case it will fail on you, is your system handling those cases?<p>I didn’t read past this:<p>> Systems like Apache ZooKeeper or Postgres (via Advisory Locks) provide the required building blocks for this<p>Zookeeper is the original sin. Convincing a whole generation of programmers that distributed lock are a feasible solution.<p>This is my biggest pet peeve in distributed systems.<p>——<p>And if you don’t believe me, maybe you’ll trust Kyle K. of Jepsen fame:<p>> However, perfect failure detectors are impossible in asynchronous networks.<p>Links to: <a href="https://www.cs.utexas.edu/~lorenzo/corsi/cs380d/papers/p225-chandra.pdf" rel="nofollow">https://www.cs.utexas.edu/~lorenzo/corsi/cs380d/papers/p225-...</a><p><a href="https://jepsen.io/analyses/datomic-pro-1.0.7075" rel="nofollow">https://jepsen.io/analyses/datomic-pro-1.0.7075</a>
Why are people going for this guys throat— distributed locking might be impossible but what is being described, distributed leasing, is totally possible and useful. There's no sins being committed here.<p>I might choose DynamoDB over S3 to implement this but both are fine.
I did the same thing 5+ years ago on GCS, using generation id.<p>And I thought S3 also supported that. I was always under impression that S3 at some point reached feature parity with GCS.<p>Are there any other fundamental features they are not equal on?
This is a very expensive way to do leader election, at least from an infrastructure perspective.<p>This is because you're essentially pushing the problem down to S3, which does its own leader election in a way that is waaaay overbuilt for what we're trying to accomplish here.<p>But... that doesn't mean it isn't cool. :)