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.

As software engineers, we deal with data abstraction every day. Trying to make sense of fuzzy real-world concepts and abstract them into structured information such as variables, functions, classes, structs, etc. that can be processed by software. Working with data almost always involves storing them into some sort of data storage, one such type of storage is relational databases, often called SQL databases. In this post we will take a ride through the normal forms of relational database to learn what they are, why they are good, and why they can be bad. We’ll only cover the first three normal forms since they are the most common in the world of mordern software engineering.

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?