A while back, I was working on building a tax engine system, one that connects accountants and household businesses to help them declare taxes. Near the end of the development cycle, we received feedback from our own accountants’ team. We hadn’t rolled out to external accountants yet; the project was still in its testing-the-waters phase. The request came from the Business Analyst at the time:
“The users cannot export data from our system, so we will need to build an export feature for them.”
While many developers use Git daily, understanding its core components can feel overly abstract. In this post, we will explore the fundamental building blocks of Git: Repositories, Commits, the Staging Area, Branches, and Merges.
In layman’s terms, a repository is simply a folder containing all your project files alongside their entire change history. It consists of your actual source code (your working directory) out in the open, plus a hidden .git folder where Git keeps all of its internal tracking mechanisms.
When an order is short on stock at a warehouse, the system creates an internal transfer request to move inventory from another location. The existing flow publishes one Kafka message per order, which triggers one transfer request per order.
During peak hours, a single warehouse can generate hundreds of these messages in minutes. Each one spawns a small transfer note. The warehouse team ends up processing dozens of tiny requests for the same destination when a single consolidated batch would do.
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.
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?