Concurrency & Interleaving

Why 1 + 1 sometimes equals 1 in distributed systems.

The idea

Imagine tracking "likes" on a post. When a user clicks like, the code says likes = likes + 1. This looks like one simple action, but under the hood, the CPU/Database actually does three steps: 1) Read the current value, 2) Add one, 3) Write the new value back. If two threads do this at the exact same millisecond, they will interleave their steps and overwrite each other, losing data.

Step 1: The database starts at Likes = 0. Two threads want to add a like.

How it works (Atomic Operations)

To fix this, we must ensure the Read-Add-Write sequence happens as an indivisible, unbreakable block. This is called an Atomic operation (from Greek atomos, meaning "uncuttable"). Databases provide specific syntax to do this safely.

# THE BAD WAY (Race Condition / Interleaving)
current_likes = db.query("SELECT likes FROM posts WHERE id = 1") # Returns 0
new_likes = current_likes + 1 
db.execute(f"UPDATE posts SET likes = {new_likes} WHERE id = 1") # Writes 1

# THE GOOD WAY (Atomic Increment)
# The database handles the read/write lock internally in a single instruction.
db.execute("UPDATE posts SET likes = likes + 1 WHERE id = 1")

# IN REDIS (Atomic INCR command)
redis.incr("post:1:likes")

Cost

Atomic operations are perfectly safe, but they force the database to serialize requests (handle them one by one rather than strictly in parallel). If you have 100,000 users clicking "like" on a single Superbowl tweet per second, an atomic SQL update will cause massive lock contention and crash the database. High-scale systems use in-memory caches (like Redis) or batching for counters.

Watch out for

ORM Traps: Object-Relational Mappers (like Prisma or Hibernate) often default to the "Bad Way". If you fetch a user object, change `user.score += 1`, and call `user.save()`, you are vulnerable to race conditions. Always look for the ORM's specific `.increment()` method.