Prevent Race Conditions Using Redis, an In-memory Storage

Have you ever tried adding the last item in ‌stock to your cart or reserving a ticket for a concert of your favourite pop artist, only to be mext with an error message? It’s frustrating! At Builder.ai, we ensure that our customers never face such issues by implementing robust backend solutions powered by in-memory storage.

As a software engineer, I’ve seen race conditions cause problems in ecommerce, ticket booking‌ and real-time systems. Race conditions occur when 2 or more requests access and modify shared data simultaneously, leading to inconsistencies..

At Builder.ai, we prevent race conditions using Redis, the most widely used in-memory key-value store. It ensures that critical operations—like updating stock, booking tickets‌ and processing payments, are happening smoothly. Other solutions like Valkey, Dragonfly DB‌ and Memcached exist, but Builder.ai relies on Redis due to its superior performance and rich feature set.

In this article, I will help you learn more about race conditions, how in-memory data storage solutions can prevent them, best practices to avoid race conditions and more. As a bonus, I’ll let you in on ‌how we solved ‌multiple invoice generation for our customers at Builder.ai using Redis.

Let’s get started!

What's a race condition?

Let's start with a real-life example. Imagine 2 users, Alice and Janice, trying to book the last available concert ticket simultaneously. Alice's request is processed first, but before the system marks the ticket as sold, Janice's request also gets processed. Now, the system has sold the same ticket twice, leading to confusion and customer dissatisfaction.

This is exactly what happens in digital systems when race conditions occur. It is when multiple requests try to change the same resource at the same time, that the system produces unpredictable results.

What are in-memory storage solutions?

In-memory storage solutions store data in your computer's memory (RAM). Because it keeps data in RAM, it can access and retrieve information very quickly, which makes it great for speeding up applications.

Now, imagine you're running an ecommerce business and you have 2 customers, Tom and Bob. They're both trying to buy the last of a popular product at the same time. Both customers add the item to their carts and proceed to checkout.

If the system doesn’t handle this properly, it might end up selling the same item to both customers, even though there was only one unit available. This is a race condition, where the system can't handle the same requests at the same time.

In-memory storage solutions can help prevent this by performing certain operations one at a time, without interruption. They make sure that only the first person who tries to buy the last ticket gets it through systems like transactions and locks. They can help here to stop multiple users from changing the same data at the same time.

How do in-memory storage solutions help in preventing race conditions?

In-memory storage solution solutions solve the problem of race conditions in several ways:

1- Atomic operations

Race conditions often lead to inconsistent updates. For example, 2 users trying to add the same item to their cart may see incorrect stock counts.

Redis provides atomic operations, ensuring that changes happen as a single, indivisible action. A command like INCR (increment) updates inventory counts instantly, preventing incorrect stock displays.

2- Optimistic state-locking

When multiple users try to book the same seat, Redis allows data locking to prevent conflicts. If one requests a lock on a resource, others must wait until the lock is released. This ensures only one transaction occurs at a time.

Best practices to avoid race conditions

At Builder.ai, the engineering team always strives to inculcate best practices and solve problems using the finest ways of engineering. We have fine-tuned our approach to preventing race conditions using Redis. Here are the key strategies we follow:

1- Use simple atomic commands

Redis processes operations like SETNX and INCR in a single step, reducing risks of race conditions.

2 - Set up locks to control access

We use Redis’ locking mechanisms to prevent multiple processes from modifying the same resource.

3 - Use data expiration

Redis ensures that outdated data is automatically removed, reducing inconsistencies.

4 - Implementing caching strategies

By using Redis as a cache, Builder.ai speeds up frequently accessed data retrieval, improving the user experience.

5 - Real-time monitoring

We use Builder.ai's AI-driven analytics to watch Redis-based transactions. We find possible race conditions before they cause problems.

6 - Scalable Infrastructure

Our cloud-based architecture ensures Redis scales with growing traffic, while maintaining high availability and performance.

7 - AI-Powered Optimization

Builder.ai leverages AI-driven insights to optimise dynamically Redis caching strategies, ensuring better performance and stability.

Builder.ai’s approach: tackling race conditions effectively

At Builder.ai, we encountered an issue with duplicate invoices. Race conditions caused many invoices to be created for the same transaction. This made it hard to check and fix them manually.

To solve this, we implemented Redis’ SETNX and EXPIRE commands to lock invoice generation. Here’s a simplified version of our code:

if some_logic

if $redis.setnx(lock_key, 'lock_acquired')

$redis.expire(lock_key, 5) # Lock expires in 5 seconds

begin

# Business logic for invoice generation

ensure

$redis.del(lock_key) # Releasing the lock

end

else

# Log race condition attempt

end

How this works:

The SETNX command locks the invoice generation process
If another request tries to make an invoice at the same time, it fails and is logged
The EXPIRE command ensures that locks don’t remain indefinitely
Once the transaction is complete, the DEL command removes the lock

By integrating Redis, Builder.ai eliminated duplicate invoices and improved financial accuracy. This same approach is used across our platform to prevent race conditions in stock management, payment processing‌ and user authentication.

Secondly, at Builder.ai, this improved the performance of our platform by caching frequently accessed data, crucial for backend. When a user interacts with Builder.ai, Redis quickly retrieves the necessary data from its in-memory storage, reducing the need to fetch it from the slower, more resource-intensive database.

This is particularly beneficial in scenarios requiring real-time data processing and quick response times, such as in ecommerce, social media and real-time analytics.

Conclusion

In-memory storage solutions can help prevent race conditions in your software by making sure that when multiple users or parts of your application try to change the same data at the same time, only one of them can do it at once.

For example, they can perform operations by introducing locking systems. By using these features, they keep your data safe and consistent, even when many people are using your application at the same time.

At Builder.ai, we prevent race conditions by using Redis for atomic operations, data locking‌ and caching. By following best practices, we ensure that multiple users can interact with our platform without conflicts.

Also, with our expertise, we build high-performance systems that handle concurrency efficiently. If you're interested in how Builder.ai is using AI to build your software, get in touch with us by clicking the banner below. 👇