Apache ZooKeeper with Spring Boot for Dynamic Configuration and Leader Election

I remember the exact moment I first felt the weight of distributed system chaos. I was sitting alone in a dim office at 2 a.m., watching logs scroll by as three microservices fighting over a shared configuration file brought down a production pipeline. The restart took six minutes. The fix took three seconds. That night I promised myself I would never again treat configuration like a file on a disk. That’s when I started looking at Apache ZooKeeper.

ZooKeeper is often described as a coordination service, but I prefer to think of it as a shared whiteboard for your services. Every instance can write to it, read from it, and most importantly, watch it for changes. When you combine ZooKeeper with Spring Boot, you get an application that can reconfigure itself in real time and coordinate its behavior with peers without ever needing a manual restart.

Let’s start with the foundation: centralized configuration. The core idea is simple – instead of putting your application properties in a file that must be redeployed, you store them in ZooKeeper under a known path. Spring Boot’s @ConfigurationProperties can be wired to read from ZooKeeper, and the best part is that changes propagate automatically. I have seen teams reduce deployment cycles from hours to seconds using this pattern. No more asking “did you push the latest config?” – ZooKeeper guarantees every instance sees the same value.

Here is a minimal Spring Boot integration using the Apache Curator framework, which is the recommended Java client for ZooKeeper.

First, add the dependency:

<dependency>
    <groupId>org.apache.curator</groupId>
    <artifactId>curator-recipes</artifactId>
    <version>5.5.0</version>
</dependency>

Then create a configuration bean that reads a node:

@Component
public class ZooKeeperConfigWatcher {

    private final CuratorFramework client;

    public ZooKeeperConfigWatcher(CuratorFramework client) {
        this.client = client;
        watchConfig();
    }

    private void watchConfig() {
        try {
            // Create or update path
            String path = "/myapp/config";
            if (client.checkExists().forPath(path) == null) {
                client.create().creatingParentsIfNeeded().forPath(path, "defaultValue".getBytes());
            }
            // Set a watcher to react to changes
            client.getData().usingWatcher((Watcher) watchedEvent -> {
                System.out.println("Config changed. Reloading...");
                // Reload application properties here
            }).forPath(path);
        } catch (Exception e) {
            // Log error but do not break startup
        }
    }
}

Now imagine you have five Spring Boot instances running across three servers. The moment you update the value in ZooKeeper via the command line or an admin panel, every instance fires the watcher and reloads its properties. No restarts. No inconsistencies.

But configuration is only half the story. The real power of ZooKeeper appears when you need services to agree on who does what. Have you ever run a scheduled task that should only execute once across a cluster? If two instances both fire at the same time, you risk duplicate processing. ZooKeeper solves this with leader election.

I once built a payment reconciliation system that had to run at midnight. If both application instances ran the job, the bank would receive duplicate requests. The fix was to use ZooKeeper’s LeaderSelector from Curator.

@Component
public class LeaderElectionService {

    private final CuratorFramework client;
    private LeaderSelector leaderSelector;

    public LeaderElectionService(CuratorFramework client) {
        this.client = client;
        startLeaderElection();
    }

    private void startLeaderElection() {
        String leaderPath = "/myapp/leader";
        leaderSelector = new LeaderSelector(client, leaderPath, new LeaderSelectorListener() {
            @Override
            public void takeLeadership(CuratorFramework client) throws Exception {
                System.out.println("I am the leader. Running critical task...");
                // Perform your once-per-cluster work here
                Thread.sleep(30000); // simulate work
                // After the method returns, leadership is released
            }

            @Override
            public void stateChanged(CuratorFramework client, ConnectionState newState) {
                // Handle connection loss gracefully
            }
        });

        // Ensure that leadership is released after failures
        leaderSelector.autoRequeue();
        leaderSelector.start();
    }
}

This code makes sure that only one instance at a time runs the task. If the leader crashes, another instance immediately picks it up. No manual intervention needed.

You might ask: how do these patterns handle high traffic? ZooKeeper itself is designed for high throughput and low latency, but you must be careful about the size of your nodes. Keep the data stored in ZooKeeper small – configuration values, not large blobs. Never store files or images there. It is a coordination tool, not a database.

So how does this compare to other tools like etcd or Consul? Each has its strengths. ZooKeeper has been around longer and its consensus algorithm (Zab) is battle-tested at massive scale. I have used it in production systems handling thousands of reads per second without a hiccup. The learning curve is a bit steeper, but once you understand the concept of ephemeral nodes and watches, the patterns become intuitive.

Ephemeral nodes deserve a special mention. When a client disconnects, ZooKeeper automatically removes these nodes. This is perfect for service discovery – a service can create an ephemeral node under a registry path when it starts, and when it dies (crashes, network partition), the node disappears. Other services watching that path instantly know the service is gone.

Let me show you a simple service registry using ephemeral nodes:

@Service
public class ServiceRegistration {

    private final CuratorFramework client;

    @PostConstruct
    public void register() throws Exception {
        String path = "/services/my-service/" + InetAddress.getLocalHost().getHostAddress();
        client.create().creatingParentsIfNeeded().withMode(CreateMode.EPHEMERAL).forPath(path);
    }
}

Now other services can discover available instances by listing children under /services/my-service. No complex DNS setup. No load balancer configuration drift.

ZooKeeper also supports distributed locks via Curator’s InterProcessMutex. Need to ensure that only one instance writes to a shared resource at a time? You can acquire a lock before writing and release it afterward. This is far more reliable than a database SELECT ... FOR UPDATE in a highly concurrent environment.

InterProcessMutex lock = new InterProcessMutex(client, "/myapp/lock");
try {
    if (lock.acquire(10, TimeUnit.SECONDS)) {
        // critical section
    }
} finally {
    lock.release();
}

Why would you use this instead of a simple database lock? Because ZooKeeper locks are distributed and survive instance crashes. If the holder crashes, the lock is automatically released after a timeout. No deadlocks.

Some teams hesitate because they think ZooKeeper adds operational overhead. I used to think the same, until I saw how much time it saves when a configuration change needs to reach 50 instances instantly. The setup is simple – run a three-node ZooKeeper ensemble for high availability, point your Spring Boot apps to it, and you are done.

I recommend starting small. Pick one microservice that frequently needs configuration changes. Migrate its properties to ZooKeeper. Then add a leader election for a scheduled task. You will quickly feel the difference between restarting containers and having your system adapt on the fly.

One caution: do not put secrets like passwords directly into ZooKeeper without encryption. ZooKeeper does not provide built-in encryption for data at rest. Use a vault or encrypt the node contents yourself. Always use authenticated client access in production.

To wrap this up: ZooKeeper plus Spring Boot gives you configuration that dances with your rollout, coordination that survives crashes, and a distributed brain for your services. It is not the newest tool, but it is one of the most reliable.

If you found this useful, please like this article and leave a comment about your own experiences with distributed configuration. I read every comment. And if you know someone still restarting services to change a database URL, share this with them. Trust me, they will thank you later.

---

As a best-selling author, I invite you to explore my books on Amazon. Don’t forget to follow me on Medium and show your support. Thank you! Your support means the world!

---

101 Books

101 Books is an AI-driven publishing company co-founded by author Aarav Joshi. By leveraging advanced AI technology, we keep our publishing costs incredibly low—some books are priced as low as $4—making quality knowledge accessible to everyone.

Check out our book Golang Clean Code available on Amazon.

Stay tuned for updates and exciting news. When shopping for books, search for Aarav Joshi to find more of our titles. Use the provided link to enjoy special discounts!

---

📘 Checkout my latest ebook for free on my channel!
Be sure to like, share, comment, and subscribe to the channel!

---

Our Creations

Be sure to check out our creations:

Investor Central | Investor Central Spanish | Investor Central German | Smart Living | Epochs & Echoes | Puzzling Mysteries | Hindutva | Elite Dev | JS Schools

---

We are on Medium

Tech Koala Insights | Epochs & Echoes World | Investor Central Medium | Puzzling Mysteries Medium | Science & Epochs Medium | Modern Hindutva