<< Go Back
Chandi Datta

Chandi Datta

Principal

Verizon

Biography:

Chandi Datta is a Datastax Certified Cassandra Architect, AWS Certified professional and has deep expertise with distributed architecture technologies. He is currently working as a Full Stack SRE engineer to solve Cassandra, MongoDB and Kafka reliability issues. Chandi is driven by challenge, and enjoys the opportunities to discover new things and new ways of learning that come with working at his current role. Chandi helped save millions of dollars of licensing cost by migrating the Mainframe stack to DSE/Cassandra. Chandi built a Change Data capture(AKA CDC) pipeline over Kafka from Cassandra to resolve Cassandra reporting challenges.

Session(s)

Distributed databases present a unique challenge especially when data has to be strictly read/written in sequential order. When it comes to Cassandra Database, Cassandra chooses availability and partition tolerance over tunable consistency. In transactions for creating user accounts or blocking MTN's, race conditions between two potential writes must be regulated to ensure that one write precedes the other. In an organization, where different people/components try to make conflicting changes to the same piece of data at the same time, how do we handle it ? Does Cassandra Database offer anything to handle this kind of service? In Cassandra Database, the Paxos consensus protocol is used to implement lightweight transactions that can handle concurrent operations. The Paxos protocol is implemented in Cassandra Database with linearizable consistency, that is sequential consistency with real-time constraints. Now the question arises, is this enough to handle conflicting use cases? In the legacy RDBMS world, an order is assigned a sequential unique Order Number based on DB2 Instance specific ranges. Autoincrement is a very useful and important feature when it comes to traditional RDBMS. Creating a global sequential sequence of numbers does not really make any sense in a distributed system. Hence there is no built-in mechanism to support that feature in Cassandra Database. So, how are we generating a unique order number to recreate the same DB2 order number logic then?