In my last post, we saw how databases achieve concurrency by creating wiggle room for interleaving non-conflicting operations through conflict-free schedules. This ability to reoder independent operations without changing the final outcome is what gives serializable systems their performance edge. But we also saw that conflicting operations fix the relative…
In my previous blog, I explored how serializability ensures isolation across transactions while linearizability guarantees real-time consistency of single objects. This post builds on that discussion by diving deeper into serializability, essentially exploring how valid serial transaction orders are nothing but a means to achieve concurrency through conflict-free scheduling. We…
How do modern databases and distributed systems ensure correctness while allowing operations to run concurrently? Two foundational guarantees — serializability and linearizability — offer different answers depending on whether you care about logical correctness or real-time visibility. In this post, we’ll explore what they are, how they differ, and why it’…
In the previous post, we understood isolation levels through the lens of their anomalies i.e., what goes wrong when transactions interleave too freely. But knowing what to prevent is only half the story. Databases must also decide how to prevent it. That’s where concurrency control mechanisms come in.…
We often think of isolation levels as checkboxes in a database configuration such as Read Committed, Repeatable Read, Serializable. But these labels are not arbitrary. They’re the database world’s answer to a simple question: What can possibly go wrong if two transactions run together? Each isolation level exists…