Cassandra Snitch
A snitch tells Cassandra about the physical and logical topology of your cluster — which data center each node belongs to and which rack it sits in. Cassandra uses this information to place replicas intelligently and to route read requests to the closest available replica, reducing latency and improving fault tolerance.
The Delivery Driver Analogy
A delivery company's dispatch system needs to know which driver is closest to each delivery address. Without that map of driver locations, it might send a driver from one end of the city across town when another driver is nearby. The Cassandra snitch is that dispatch map — it tells Cassandra exactly where each node lives so reads and writes travel as short a distance as possible.
What a Snitch Does
A snitch answers two questions about each node:
Question 1: Which data center does this node belong to? Question 2: Which rack within that data center does this node sit in? Cassandra uses these answers to: ✓ Place replicas across different racks (avoids rack-level failure) ✓ Place replicas across different data centers (avoids DC-level failure) ✓ Route read requests to the nearest replica (reduces latency) ✓ Perform local reads in multi-DC clusters without cross-DC hops
Types of Snitches
SimpleSnitch
SimpleSnitch treats the entire cluster as one data center with one rack. It is the default for new installations. Use it only for single-node development or learning environments — it provides no rack awareness and no multi-DC support.
# cassandra.yaml endpoint_snitch: SimpleSnitch
GossipingPropertyFileSnitch (Recommended)
GossipingPropertyFileSnitch reads rack and data center information from a local file on each node (cassandra-rackdc.properties) and spreads that information to other nodes via gossip. It is the recommended snitch for all production deployments because it supports multiple racks and data centers and requires no external service.
# cassandra.yaml endpoint_snitch: GossipingPropertyFileSnitch # cassandra-rackdc.properties on each node: dc=us-east rack=rack1
Cluster layout with GossipingPropertyFileSnitch: Node A: dc=us-east, rack=rack1 Node B: dc=us-east, rack=rack2 Node C: dc=us-east, rack=rack1 Node D: dc=eu-west, rack=rack1 Node E: dc=eu-west, rack=rack2 Replica placement (RF=2 per DC, NetworkTopologyStrategy): us-east: Node A (rack1) + Node B (rack2) → different racks ✓ eu-west: Node D (rack1) + Node E (rack2) → different racks ✓
PropertyFileSnitch
PropertyFileSnitch reads topology from a cluster-wide file (cassandra-topology.properties) that maps IP addresses to data centers and racks. You must maintain this file on every node. GossipingPropertyFileSnitch is easier to manage because each node only needs its own local file.
# cassandra-topology.properties 10.0.0.1=us-east:rack1 10.0.0.2=us-east:rack2 10.0.0.3=eu-west:rack1
EC2Snitch
EC2Snitch automatically determines the data center and rack from AWS metadata. It maps AWS regions to Cassandra data centers and availability zones to racks. Use this when running Cassandra on Amazon EC2 without a VPC.
endpoint_snitch: EC2Snitch # Automatic mapping: # AWS Region us-east-1 → data center us-east # AWS AZ us-east-1a → rack 1a # AWS AZ us-east-1b → rack 1b
EC2MultiRegionSnitch
Like EC2Snitch but designed for clusters that span multiple AWS regions. It uses the public IP address for inter-region communication and the private IP for intra-region traffic.
endpoint_snitch: EC2MultiRegionSnitch
GoogleCloudSnitch
GoogleCloudSnitch reads topology automatically from Google Cloud Platform metadata. It maps GCP regions to data centers and zones to racks.
RackInferringSnitch
RackInferringSnitch infers the data center and rack from the node's IP address. It uses the second octet of the IP as the data center identifier and the third octet as the rack identifier. This requires careful IP planning but works without any configuration file.
IP: 10.12.14.4
── ──
DC Rack
12 14
Data Center: 12
Rack: 14
Snitch Comparison Table
Snitch Config Needed Best For ────────────────────────────────────────────────────────────────────── SimpleSnitch None Dev / single node GossipingPropertyFileSnitch Local file per node Production standard PropertyFileSnitch Global file Small manual clusters EC2Snitch None AWS single-region EC2MultiRegionSnitch None AWS multi-region GoogleCloudSnitch None GCP deployments RackInferringSnitch IP plan only IP-based topology
Changing a Snitch in Production
Changing the snitch type on a running cluster is a multi-step process. You must update cassandra.yaml on every node, restart nodes one by one, and then run nodetool cleanup to remove data that is no longer owned by each node. Always test this procedure in a non-production environment first.
Step 1: Update cassandra.yaml on all nodes Step 2: Update cassandra-rackdc.properties on all nodes Step 3: Perform a rolling restart (one node at a time) Step 4: Run nodetool cleanup on each node after restart
Verifying Snitch Configuration
# Check what DC and rack this node reports: nodetool info | grep -i "data center\|rack" # View all nodes with their DC and rack: nodetool status Datacenter: us-east =================== Status=Up/Down -- Address ... Rack UN 10.0.0.1 ... rack1 UN 10.0.0.2 ... rack2
Summary
The snitch provides Cassandra with a map of the cluster's physical topology. It identifies each node's data center and rack, enabling intelligent replica placement and low-latency read routing. GossipingPropertyFileSnitch is the recommended choice for production because it is flexible, does not depend on external services, and propagates topology automatically through gossip. Cloud-specific snitches (EC2Snitch, GoogleCloudSnitch) eliminate manual configuration on their respective platforms.