In our previous post we covered read committed isolation level. Read committed isolation level ensures that: We cannot perform reads across transactions It prevents dirty…
Transactions: Read committed isolation
Ensuring that each resource is accessed and modified by a single user at a time is very complex on the application layer. This is why…
Transactions: Atomicity & Isolation
In last post, we saw the use case of why we need transactions to maintain a consistent state of our storage system. A database is…
Transactions: Why we need all or nothing?
In real life applications, things can go wrong for scenarios which you have never considered while designing the application. These failures can happen due to…
Partitioning: Handling secondary indexes in partitions
Up until now we have discussed partitioning in a system where we are able to store a record in a partition and retrieve from the…
Partitioning: Consistent Hashing
While ending our discussion on various approaches to partitioning, we saw how the typical hashing approaches fail when we encounter a node failure or when…
Partitioning: Approaches to partitioning
Before diving into approaches to partition a database, let us clear up one thing in aspect of partition and its relationship with replication. Partitioning &…
Partitioning: Introduction to partitioning
Until now we have seen how replication helps in scaling a read-intensive workload. We keep one or more nodes as leaders that handle write traffic…
Replication: Handling Concurrent Writes
In all the replication methodologies, we have seen a common issue which all of the replication methods fail to solve completely and that is handling…
Replication: Maintaining a Quorum
In Introduction to Leaderless Replication we saw that Quorum plays a huge part. We need some way to ensure that storage operations are persisted correctly…