I’ve been at DataStax for over six years now (seven-year anniversary coming up in July) and I’ve been privileged to witness customers do some amazing things with DataStax Enterprise (DSE) and Apache Cassandra™. But at this point with DataStax, one thing stands out to me over everything else:
We have customers who have been with DataStax as long as I have who have not experienced a single second of data platform downtime.
As someone who’s worked in database tech for decades now, that fact really blows me away. Customers like Walmart, eBay, Netflix, and others who use DSE and its Cassandra foundation may have seen hiccups and outages in other areas of their infrastructure, but not their data layer. It’s literally been on and alive for over six years, across version upgrades and even hardware migrations.
How is that possible?
The Simple Explanation
When I tell non-tech people what I do for a living, they usually need some kind of example for it to make sense. So, I typically pull out my phone, talk about the digital apps that everyone has, and say: “We deliver the information these apps and you need anywhere, anytime, all the time.” That’s the simple but powerful value that DataStax solutions deliver.
Now, to be able to provide these types of applications, there’s a simple—yet very difficult—requirement: you have to be able to not just read data from anywhere 24x7x365, but write changes to it as well, and then make sure it’s up to date and available in multiple locations. The concepts of write-anywhere and location independence ensure not only consistent performance for distributed applications but also 100% uptime, at least as far as the data layer is concerned.
Given that this requirement is pretty much table stakes in our digital world, you’d think a lot of database vendors would be able supply this capability. But you’d be wrong.
The Simple Foundation
What does it take to pull off read-write anywhere and location independence? It’s a matter of architecture.
Almost all major database vendors fall into two different architectures where distributing data is concerned: (1) master-slave; (2) multi-master. While fine for centralized or semi-distributed apps, these designs are fundamentally ill equipped to handle widely distributed systems, such as most of the digital applications we use today.
A third architecture—masterless—is used by DataStax/Cassandra and is currently fairly unique to the database scene, at least where major vendors are concerned. A masterless design allows users to read and write their data to any node in a cluster and have it automatically replicated and synced with other copies of that data in multiple locations. It’s this masterless architecture that gives DSE/Cassandra the ability to deliver true constant uptime over other database management system providers. 
It probably comes as no surprise that all of the relational database management system vendors are master-slave and/or multi-master. But you may be surprised to learn that almost all NoSQL vendors have the same design.
MongoDB? Replica sets and master-slave (primary/secondary).
Couchbase and Redis? Master-slave.
What about some of the big cloud vendor’s NoSQL platforms, like Microsoft Cosmos DB? Master-slave and multi-master. Amazon DynamoDB? Even with its global tables option, DynamoDB is still master-slave and multi-master. Also, don’t forget that both Cosmos DB and DynamoDB are proprietary products specific to their cloud owners, so you won’t get the data autonomy (e.g. the ability to run both on premise and on multiple clouds) with them that you get with DSE.
Getting back to the architecture differences, DSE’s masterless architecture exceeds both master-slave and multi-master designs, which require much more work to achieve even a semblance of high availability and have no chance of reaching continuous availability, which is what today’s digital applications require.
For example, as reported by Amazon, the downtime experienced by DynamoDB speaks to the difference I’m highlighting. Don’t get me wrong—this isn’t to point fingers at Amazon’s or Microsoft’s infrastructure, which is probably better than average overall. The point is that you need a database that can tolerate outages with no loss of availability.
How About You?
If you’d like the comfort of knowing your applications’ data layer won’t ever go down and want to experience the same uptime as many DataStax customers, check out our resources page to learn more or visit DataStax Academy for free, go-at-your-own-pace online education that shows you how to deploy always-on apps that keep your enterprise not just open for business but thriving in the Right-Now Economy.
