Apache Cassandra
Multi-Datacenter Deployment
Understand the design considerations and configuration required to run Cassandra reliably across multiple datacenters or cloud regions.
Cassandra runs across datacentres as a normal configuration, not an add-on. That is a genuine difference from most databases, and the reason many teams choose it.
It's like a multinational company keeping a full copy of important records in every regional office, letting each office's staff work from their local copy at full speed for day-to-day business, while a background courier service keeps quietly syncing updates between all the offices so no single office's records ever fall permanently behind.
Key Concepts
1
How it is set up. Replication factor per datacentre, and a consistency level that stays local:
2
replication = {'class': 'NetworkTopologyStrategy',
'mumbai': 3, 'virginia': 3}3
Six copies, three in each region. Then applications use LOCAL_QUORUM, so a write needs two of the three
local replicas and never waits for the other continent.
LOCAL_QUORUM
4
Replication still happens — just not in your latency. The coordinator sends the write to the remote
datacentre regardless of consistency level. It simply does not wait for it before answering the client.
5
client -> mumbai coordinator
mumbai replicas x2 ack -> client gets success (~5 ms)
virginia replicas -> arrive shortly after, asynchronously6
So the data converges everywhere while the user waits only for the local majority. Get this the wrong way
round in an interview — claiming plain QUORUM is fine across regions — and you have added a 200 ms
round trip to every write.
QUORUM
7
What you give up. Write in Mumbai and read in Virginia immediately, and the data may not be there yet.
Across datacentres the system is eventually consistent, and no local consistency level changes that.
Designs that need read-after-write across regions need the read routed to the writing region.
8
The analytics datacentre pattern. Add a third datacentre holding a full replica, and point no
application traffic at it:
9
mumbai RF 3 <- live traffic
virginia RF 3 <- live traffic
analytics RF 2 <- Spark jobs only10
Spark can scan entire tables there without affecting production latency, because no live query is
coordinated by those nodes. The isolation is by routing, not by configuration — clients simply never
choose it as coordinator, which the driver's local-datacentre policy handles.
11
What goes wrong in practice.The driver is not datacentre-aware. Then it happily picks a remote coordinator and every request crosses
the ocean. The driver's local datacentre name must be set, and it must match the snitch's name exactly.
12
Cross-DC bandwidth was not planned. Repair, bootstrapping a new node, and hint replay all stream data
between regions. Adding a node in Virginia can saturate the link and slow live traffic. Streaming
throughput can be throttled, and should be.
13
The snitch is wrong, so NetworkTopologyStrategy cannot tell the datacentres apart and places replicas
somewhere you did not intend.
NetworkTopologyStrategy
14
What the interviewer is probing.1. "Why run multiple datacentres?" Probing: the reasons. Stalls: "Redundancy." Moves up:
regional latency, disaster recovery, and isolating analytical workloads from transactional ones in a
separate logical datacentre.
15
2. "Which consistency level should clients use?" Probing: the practical answer. Stalls:
"QUORUM." Moves up: LOCAL_QUORUM, so operations do not wait on cross-datacentre latency.
16
3. "How does replication work across datacentres?" Probing: the mechanism. Stalls:
"Synchronously." Moves up: the coordinator forwards to one node per remote datacentre, which fans
out locally — and it is asynchronous from the client's perspective at LOCAL levels.
17
4. "What must the driver be configured with?" Probing: the detail. Stalls: "Nothing." *Moves
up:* a datacentre-aware load balancing policy, or it will route requests across regions.