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, a rate limiter. When you design with that mindset, you naturally build in safeguards, such as database unique constraints, idempotency keys, retry-safe operations. The failure modes Kleppmann describes are real, but they’re survivable in systems that don’t 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.

Have you ever studied or worked with databases and come across abbreviations such as ACID, BASE, CAP and wondered what these words mean? I have and this post is the result of my research on this topic.

CAP is a type of headwear?

CAP stands for Consistency, Availability, Partition-tolerance first introduced by Eric Brewer in a talk in the year 2000. Brewer said that in a distributed system, in the event of a partition (of the network, or communication between nodes in the system), the said system can only choose between consistency or availability not both. What are these properties, and why can we not choose both?

While working with backend systems, there is a common pattern when handling incoming data. We usually have a server waiting to receive data from a message broker or an API. When the data arrives, we process the data based on the business contract and then insert or update that data into the database before also transmitting the data to the next server via a message broker or an API. This data processing pattern is called a dual write, sometimes also called multi-write or sync-write.