Thoughts on Software Design & Development
“Our bodies will stay always as they are, fresh and alive, but we must never hesitate to bring death, because it is how we live.” — Lestat, Interview with the Vampire The unwritten rule among vampires was broken the night Claudia was made. She was never supposed to
I run dark mode everywhere macOS, browser, editor, terminal. At this point its not really a preference anymore. Bright white screens for hours genuinely strain my eyes. That setup worked perfectly until I started using Hide My Email, Apple’s privacy feature that generates random relay addresses for signing
In my last post Bloom Filters: MathMania , we worked through the derivations for optimal number of bits to allocate and the right number of hash functions to use – striking a balance between space, computation, and false positives. But all of that math rested on one simple assumption: the set
So, you’ve come across Bloom filters and understand that, despite their probabilistic nature, they are a great fit for your use case. You’ve decided to integrate them into your system design, but you’re unsure about the optimal size and the number of hash functions
Durability requirements influence the choice of data protection mechanisms, such as replication, erasure coding, and RAID parity configurations. Achieving higher durability involves trade-offs between redundancy , storage usage ratio , and computational complexity . Replication achieves durability by creating multiple copies of data, which increases redundancy but reduces the storage usage ratio.…
This blog post is another take at isolation levels , a topic I first explored in one of my earlier posts . The motivation this time is to relook at isolation levels from a different perspective so that isolation levels feel understood rather than merely studied . In a previous post , we saw
In my last post , we saw how databases handle conflicts through different philosophies i.e., prevention , validation , versioning , and observation , allowing transactions to run concurrently without violating serializability. But avoiding or resolving conflicts isn’t the end of the story. Even after all conflicts are managed, the database still
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,
In the previous post , we looked under the hood at how databases enforce isolation through locks, validations, and snapshots. Although these isolation levels were already introduced in the earlier post, we’ll revisit them here to clear up one of the most common sources of confusion i.e., the
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
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
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,
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