> For the complete documentation index, see [llms.txt](https://note.levelcode.org/software-engineering-notes/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://note.levelcode.org/software-engineering-notes/race-condition.md).

# Race Condition

If you don't know what is race condition, please read it briefly here:

{% embed url="<https://en.wikipedia.org/wiki/Race_condition#In_software>" %}

I'll explain some ways how to handle race condition here:

* **Pessimistic locking**
  * Explicitly locks a resource from being accessed simultaneously.
  * Usually done on relational DB by using `SELECT ... FOR UPDATE` query.
  * Using [Redis](/software-engineering-notes/database/in-memory-redis.md) for distributed lock also falls into this category.
  * More performance overhead than optimistic locking.
  * Might cause deadlock if not careful.
  * More reliable than optimistic locking especially if the write amount is high and the possibility of race condition is high.
* **Optimistic locking**
  * Done by checking the data version/timestamp/hash when reading the data and writing the data (version/timestamp/hash must be the same when reading and writing the data).
  * In relational DB, you'll know how many rows are affected by the operation, which will help to detect whether or not the operation on the data is executed.
  * Might be suitable if there are more reads than write.
  * User should be notified that the data is updated (by another session or person) already.
* **Ordered queue**
  * For example, it is possible to use Kafka which ensures ordering within the same partition. This might be more suitable if there's already a message broker in use.
  * Another simple example is to use database as the queue and the tasks can be executed by a worker one by one based on the rows on the database.

Other than that, there might be other way to handle or reduce race conditions. For example, if a website only sells 100 tickets, it might be okay to only allow only 100 people to access the page at the same time. Though, it might still need to apply one of the solutions above.

On a relational DB, you might be able to avoid using lock if what you need is just to increase (or decrease) a column's value. Example query: `UPDATE account SET point_amount = point_amount + 5 WHERE id=1;`.

{% embed url="<https://stackoverflow.com/a/129397>" %}

{% embed url="<https://stackoverflow.com/a/67014217>" %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://note.levelcode.org/software-engineering-notes/race-condition.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.