Cassandra Architecture

Cassandra is designed in such a way that, there will not be any single point of failure. There is no master- slave architecture in cassandra. cassandra addresses the problem of SPOF by employing a peer-to-peer distributed system across homogeneous nodes where data is distributed among all nodes in the cluster. In cassandra all nodes are same. There will not be any master or slave in cassandra. Each node frequently exchanges state information about itself and other nodes across the cluster using peer-to-peer gossip communication protocol.

Cassandra is a partitioned row store database, where rows are organized into tables with a required primary key.Clients read or write requests can be sent to any node in the cluster. When a client connects to a node with a request, that node serves as the coordinator for that particular client operation. The coordinator acts as a proxy between the client application and the nodes that own the data being requested. The coordinator determines which nodes in the ring should get the request based on how the cluster is configured.

Key components in cassandra

  • Gossip protocol: Cassandra uses gossip protocol to communicate with other nodes.Gossip is a peer-to-peer communication protocol in which nodes periodically exchange state information about themselves and about other nodes they know about. The gossip process runs every second and exchanges state messages with up to three other nodes in the cluster. The nodes exchange information about themselves and about the other nodes that they have gossiped about, so all nodes quickly learn about all other nodes in the cluster. A gossip message has a version associated with it, so that during a gossip exchange, older information is overwritten with the most current state for a particular node.


  • Seed nodes: There will be few seed nodes in the cassandra cluster, the main purpose of seed nodes is to bootstrapping the gossip process for new nodes joining the cluster. Seed nodes are not a single point of failure, nor do they have any other special purpose in cluster operations beyond the bootstrapping of nodes. In multiple data-centre clusters, the seed list should include at least one node from each data centre 

Data distribution and replication

Following sections will explain you about how data will be distributed and the process of replication in cassandra cluster.

  • Virtual nodes (Vnodes): In cassandra, each node will be assigned by a unique token. data distribution and replication among the nodes will be based on these unique tokens. Before Cassandra 1.2, each node is assigned with a token. After cassandra 1.2, each node is assigned with group of tokens as shown below,


  • The top portion of the graphic shows a cluster without vnodes. In this paradigm, each node is assigned a single token that represents a location in the ring. Each node stores data determined by mapping the partition key to a token value within a range from the previous node to its assigned value. Each node also contains copies of each row from other nodes in the cluster. For example, if the replication factor is 3, range E replicates to nodes 5, 6, and 1. Notice that a node owns exactly one contiguous partition range in the ring space.
  • The bottom portion of the graphic shows a ring with vnodes. Within a cluster, virtual nodes are randomly selected and non-contiguous. The main advantage of vnodes is data will not be replicated in continues nodes. so if a group continues nodes went down in a cluster then there is chance for data loss, so this is overcome by vnodes.
  • Replication strategy/data replication: Data replication is nothing but maintain duplicates of data.
    • If replication factor is 1, then there will be only one record of a row in any one of the node in a cluster
    • If it is 2, then it maintains 2 copies of each row, in a different nodes of a cluster.
    • In cassandra, all replicas are same, there will not be any primary or secondary replicas.
    • Generally, replication factor should greater then 1 and less then number of nodes in a cluster.
  • Types of replication strategies:
    • SimpleStrategy: Use this strategy, only if you have one data centre in the cluster.
    • NetworkTopologyStrategy: Use NetworkTopologyStrategy when you have multiple data centres in a cluster. NetworkTopologyStrategy will replicate data in to multiple nodes of different data centres.
  • Data partitioning: Till now we have discussed  about data replication(storing data duplicates). now we will discuss about data partitioning, means how to distribute the data across the nodes in the cluster. Basically, a partitioner is a hash function for computing the token of a partition key. There are 3 types of partitioner’s in cassandra.
    • Murmur3Partitioner (default):  Uniformly distributes data across the cluster based on MurmurHash hash values.
    • RandomPartitioner: Uniformly distributes data across the cluster based on MD5 hash values.
    • ByteOrderedPartitioner: Keeps an ordered distribution of data lexically by key bytes.
  • Snitch: A snitch defines groups of machines into data centres and racks (the topology) that the replication strategy uses to place replicas. The default SimpleSnitch does not recognize data centre or rack information.The GossipingPropertyFileSnitch is recommended for production. The following are different types of snitchs.
    • dynamic snitching
    • simple snitching
    • RackInferringSnitch
    • PropertyFileSnitch
    • GossipingPropertyFileSnitch
    • Ec2Snitch
    • Ec2MultiRegionSnitch
    • GoogleCloudSnitch
    • CloudstackSnitch

About Siva

Senior Hadoop developer with 4 years of experience in designing and architecture solutions for the Big Data domain and has been involved with several complex engagements. Technical strengths include Hadoop, YARN, Mapreduce, Hive, Sqoop, Flume, Pig, HBase, Phoenix, Oozie, Falcon, Kafka, Storm, Spark, MySQL and Java.

Leave a comment

Your email address will not be published. Required fields are marked *

Review Comments
default image

I have attended Siva’s Spark and Scala training. He is good in presentation skills and explaining technical concepts easily to everyone in the group. He is having excellent real time experience and provided enough use cases to understand each concepts. Duration of the course and time management is awesome. Happy that I found a right person on time to learn Spark. Thanks Siva!!!

Dharmeswaran ETL / Hadoop Developer Spark Nov 2016 September 21, 2017