When to use Cassandra and why?

Let’s look at some of the use cases of Cassandra:

Feature of Masterless Replication for high availability

• It relies on a masterless model. In this model, all nodes actually behave the same, each storing a subset of the data. There is no master or slave. If we were to insert a new row in the database, it will go to at least one of these nodes and get replicated to a certain number of nodes. 
• When we ask for our row, the nodes gossip among one another to find out who holds that piece of data and return it to us. In fact, all nodes can serve requests for any piece of data, even if they don’t actually hold it. All of this is actually managed by the database nodes in the cluster with no intervention from us. The nodes in the cluster are aware of the cluster, they know they are running in a distributed environment and constantly talk to each other(In fact, they talk so much to each other that this kind of talking is called gossiping). To know more about gossiping in Cassandra, click here. 
• We don’t have to worry too much about managing masters and slaves. The entire system is built from homogeneous nodes, so we just specify the number of nodes we want and that’s it. There is no need for master elections, no single point of failure, and it’s easy to manage and work with.

Feature of Tuneable Consistency:

• Cassandra offers a tunable consistency model. In this model, Cassandra allows the developers to choose which level of consistency they want. We can choose between eventual consistency or strong consistency at the cost of availability. 
• Distributed database systems generally fall into two categories, AP systems which maximize availability over consistency, and CP systems which emphasize consistency over availability. There is no right or wrong system here, it just depends on what matters to your application, consistency, or availability. Cassandra is usually described as an AP system, it is generally used in part due to its high availability. However, we can control or tune the balance between availability and consistency. It is impossible to achieve both in any system as the CAP theorem explains so the only thing we can do is trade one with the other. 
• The way we control consistency is by using consistency level and replication factor. These dictate how many times our data is replicated, how many nodes must write the data synchronously before the response is returned to the user, and how many nodes must return the data when reading. Thus, in short, Cassandra is usually used as an eventually consistent distributed system, but it can be tuned and configured to support stricter levels of consistency.

Feature of High Write Performance:

• Since we would generally have a lot of nodes in a Cassandra cluster and each node can perform writes, we get a good write performance. This level of write performance is simply not possible with a single master and multiple slave architecture in a relational database. And using a multi-master system usually comes with complexities.

A distributed NoSQL database management system called Apache Cassandra was made to manage massive volumes of structured and semi-structured data across a number of commodity servers. Initiated by Facebook, it was subsequently open-sourced in 2008. Cassandra is renowned for its great scalability, fault tolerance, and high availability. It is based on the same ideas as Amazon’s Dynamo and Google’s Bigtable.

The architecture of Cassandra is built on a decentralized approach, in which every node in the cluster is identical and has a copy of the data on it. Data is divided across the nodes using a distributed hash table, and replication is employed to guarantee high availability and durability. Moreover, Cassandra features configurable consistency, which enables customers to strike a compromise between data availability and consistency.

Cassandra works really well if we want to write and store a large amount of data in a distributed system and don’t care much about ACID with good performance.