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…
In the previous post, we saw how distributed systems escape the chaos of unreliable clocks by using logical time to measure causality instead of seconds. But there’s one domain where time keeps sneaking back in i.e., Coordination. And as already explained in Part I of this series, coordination…
In the last post, we saw how physical clocks betray us! They drift, skew, jump, and bend, creating logs where effects appear before causes and refunds happen before payments. So what do we do when time itself can’t be trusted? We stop measuring time, and start measuring causality. Second…
Distributed systems often behave as if time were universal, objective truth as if two machines agreeing on a timestamp meant they also agreed on the order of events. But clocks in computers are not laws of nature! They drift with time, freeze under load, stumble over leap seconds, and lags…