Exploring CAP theorem trade-offs and different types of databases based on trade-offs
First, let’s grasp the concept of the CAP theorem. Subsequently, the CAP theorem, also known as Brewer’s theorem, posits that a database can effectively ensure a maximum of two out of three assurances: Consistency, Availability, and Partition Tolerance.
Consistency: Consistency in the CAP theorem means that all nodes in a distributed system see the same data simultaneously. It ensures data uniformity across the system, but achieving it might affect availability and partition tolerance.
Greater consistency results in increased latency within the system, since the time required for data replication/propagation among nodes is extended.
Availability: “Availability” in the context of the CAP theorem means that a distributed system ensures that operational nodes respond to user requests even in the face of failures. This can result in potentially providing slightly outdated or inconsistent data.
This pertains to the replication of data across nodes, ensuring redundancy within the system. Consequently, in the event of a node failure, the replica must be capable of fulfilling data requests.
Here’s a memorable tale from about 5 to 7 years ago when we were redesigning our platform. Back then, a friend of mine, who worked as an architect, was explaining our new design to a senior leader.
In this plan, we included extra copies and safety nets to deal with possible problems. Our main goal was to make sure the system was up and running most of the time.
Examining the backup plan, the individual grew annoyed and questioned, “Why so much emphasis on backup, backup, backup?” This led to a discussion about the potential consequences if the system experienced downtime. Would it impact the business, and if it did, how significantly? Unfortunately, we lacked a concrete response. Despite this, after the meeting, we found humor in the situation and playfully teased our architect friend about it.
As I look back on it, that incident actually raised an important question that every architect should think about when designing something. It’s about matching what the business really needs with what we’re making. Are the business goals and what we’re building on the same page? And, is the business willing to pay for keeping the system available? Remember, everything has a cost — there’s no such thing as a free lunch.
Partition-Tolerance: Partition tolerance, in the CAP theorem, is a system’s capability to operate despite network disruptions. It ensures availability during communication failures but might lead to consistency trade-offs.
Even if some nodes within the system are not operational or if there are network failures, the system should maintain its functionality without any disruption.
Let’s look into database types considering the trade-offs posed by the CAP theorem.
Examples of CA type DBs: Google Cloud Firestore, SAP MaxDB, MemSQL, SAP IQ (Sybase IQ), VoltDB, Teradata, Google Cloud Datastore, Microsoft Azure Cosmos DB, Amazon RDS (Relational Database Service), IBM Cloudant, Oracle NoSQL Database, ArangoDB
Examples of CP type DBs: MySQL, MongoDB, Oracle Database, Microsoft SQL Server, PostgreSQL, HBase, Aerospike, Google Cloud Spanner, RDBMS, Neo4j, SAP HANA, CockroachDB, IBM Db2, Hazelcast, TiDB, VoltDB
Examples of AP type DBs: Cassandra, DynamoDB, Couchbase, ScyllaDB, RavenDB, RethinkDB, Riak, MongoDB, Redis
Please bear in mind that every database has a distinct design and intended purpose. For instance, relational databases like RDBMS or MySQL prioritize consistency as their primary objective. Furthermore, the behavior of a particular database can also be influenced by its configuration choices.
More: https://ajhawrites.blogspot.com/2023/08/exploring-cap-theorem-trade-offs-and.html
Follow me here as well: https://hubpages.com/@ajhawrites
