I recently got into a very heated discussion with GPT5-point-something over the ACID guarantees provided by Redis. The discussion boiled down to the following - GPT, and much of the internet claims that Redis is atomic. I disagree. To be fair the disagreement is more about the popular definitions of atomicity than it is about Redis internals.
Most engineers I’ve talked to confuse atomicity and isolation, and I don’t blame them. It’s very easy to do so. I would attribute this confusion to the atomic counters everyone built in their OS classes in college. That scenario looks like this - you’re running multiple threads and want to increment a shared counter. Usually you’d go for locks. But you can avoid those if the “increment” operation is atomic. In other words, if the operation executes as a single unit then it’ll either be executed completely or it won’t, and the thread that is executing it will not be interrupted midway by the OS.
The same scenario gets a little more nuanced when we talk about database transactions.
- Atomicity: If 1 transaction is doing multiple writes, and it fails midway, will it roll back the writes? Atomicity therefore is equivalent to rollback-ability.
- Isolation: If 2 transactions are being executed at the same time, will they interfere with each other? Isolation exists on a spectrum. One of the extremes being serializable isolation, in which they appear to run one after another, avoiding any interference.
If we go by this definition then the Lua scripts that Redis executes are not atomic. Any failures mid-way through execution will not cause partial writes to be rolled back. But all Redis operations are indeed isolated since they literally execute one after the other on a single thread.