Sunil DabreDistinguished Engr Full Stack
Sunil Dabre is a Datastax Certified Cassandra Architect, has deep expertise with distributed architecture technologies. He is currently working as a Distinguished Full Stack SRE engineer to solve architecture reliability issues. Sunil Dabre has 20+ years of industry experience, strongly committed to Innovation and Excellence in Delivery. He is proficient in modern architectures for large scale / low latency IT systems and software development patterns . Sunil is driven by challenge, and has a unique ability to apply technology to solve complex business requirements. He has immense experience in delivering transition architectures from legacy to modern directional systems.
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?