Breaking with Zookeeper is a critical misstep. A lockservice is the critical core of any distributed system. The hardest problem in distributed systems is seria

Breaking with Zookeeper is a critical misstep. A lockservice is the critical core of any distributed system. The hardest problem in distributed systems is serialization and consensus - A lockservice provides important tooling to solve both, in a way that can be portable and consistent across diverse systems. Master election? As simple as who owns the lock. Serialization? Do an atomic update on the lockserver of the pointer-reference to the datastructure, or simply grab a lock for the duration of the commit. Service discovery? Use ephemeral nodes and prefix-scanning to discover who's online. These solutions are tried and true, but frequently ignored, as each new tooling re-invents the wheel and builds it's own infrastructure... Including Kafka, which can't decide if it's part of the Hadoop stack or it's own complete solution, and is therefore suitable for neither. I'm actually in favor of breaking with Zookeeper (It's terribly designed, has serious problems with concurrency and even consistency, and has the classic java problem of using java's internal serialization methods, which are utterly unfit for storing more than temporary data on a single host.) However, absorbing all of the demands of a lockservice into every product is not the solution to Zookeeper's failures.