Almost two years ago, in my Dual Write post, I introduced a few patterns for handling dual writes and said I might explore them in more detail later. That took a while, but here we are. If you haven’t read that post, it covers the problem and why simply reordering the writes or retrying in memory doesn’t solve it.

The idea behind these patterns is simple: when we can’t make two writes to independent systems atomic, we make one follow from a durable record of the other. In the e-commerce example from the previous post, the search service indexes a listing after its database record has been saved, or after an event to create it has been durably published. That distinction matters for the listen-to-yourself pattern, as we’ll see later. Either way, the search service needs a reliable way to learn about the listing so buyers can find it.

Despite the critique in my previous post, I still believe Redlock is a valuable algorithm, both as a practical tool and as an entry point into distributed systems thinking.

In my experience, its theoretical downsides rarely translate into real-world catastrophes. Why? Because engineers who choose Redis typically aren’t betting everything on it. They treat Redis as fast but fallible: a caching layer or a rate limiter. With that mindset, you naturally build in safeguards such as database unique constraints, idempotency keys, and retry-safe operations. The failure modes Kleppmann describes are real, but systems can survive them if they do not assume perfection.

TL;DR: Redis is an AP system, not a CP system. It cannot guarantee strong consistency. For high-concurrency use cases, expect potential data races when using Redis. Consider systems that provide strong consistency (e.g., etcd, ZooKeeper) if you need strict guarantees.

The Single-Instance Lock

In the previous post, we explored how to implement a distributed lock using a single Redis instance. We addressed the question: what if the client crashes? But we left one critical question unanswered: what if Redis itself fails?

Note: Code examples in this article use Go. The concepts apply to any language.

Why lock at all?

Imagine two users trying to withdraw money from the same bank account simultaneously. Without proper synchronization, both might read the same balance, deduct their amounts independently, and write back—resulting in a lost update. One withdrawal effectively disappears.

This is a classic race condition: the correctness of the outcome depends on the timing of operations.

These are some of the resources I found or stumbled upon on the internet throughout my life; most of the things here I personally found to be valuable and/or funny. I try to only add free web content here, so that you only need a web browser to access, no bs required. Enjoy! Hope you like it.

Software Design

Design Patterns - Refactoring.Guru

Introduction to a lot of common design patterns, plus the humor.