Neo4j: The Definitive Guide

Chapter 10. Clustering and Sharding

As ElectricHarmony’s graph grew in size and value, so did the expectations around reliability. Outages that were once tolerable became unacceptable. A failed write during a peak event could mean lost revenue, or worse, a corrupted view of their users’ listening habits. The team knew it was time to move beyond a single-node setup.

This chapter introduces clustering in Neo4j, the foundation for building highly available graph deployments. You’ll explore how Neo4j’s architecture supports fault tolerance, how leader elections and replication work, and what trade-offs come with scaling for resilience.

From setting up a basic cluster to understanding how reads and writes behave across members, you’ll learn how ElectricHarmony transitioned from a single point of failure to a robust cluster capable of handling both growth and unpredictability.

High availability isn’t just a feature—it’s a necessity. Let’s dive in.

Clustering for High Availability

When performance and uptime are critical, running Neo4j as a standalone instance no longer cuts it.

Neo4j’s clustering model is designed to keep your database available even in the face of hardware failures, maintenance windows, or surging traffic. Clustering doesn’t just improve resilience; it also enables the system to scale read capacity across multiple machines.

Figure 10-1 starts with a very basic cluster to introduce you to some of the clustering concepts.

Figure 10-1. A basic Neo4j cluster with three ...