Scalable Human Blog

Let’s begin with understanding, on how do we decide whether two operations are concurrent or not?

Consider this scenario:

• Client A inserts a row into a table
• Client B updates that new row

The two writes are not concurrent…

• A insert happens before Bs increment
• Because the value incremented by B is the value inserted by A
• In other words…
  • B operation builds upon A’s operation
  • So B operation must of happened later
  • We also say B is casually dependent on A

On the other hand:

• The two writes in our 3 node datastore example are concurrent
  • When each write starts the operation
    • It does not know that another client is also performing an operation on the same key
    • There is a casual dependency between operations
      • If operation A happen before another operation B, if B knows about A or depends on A or builds upon A in some way

How to define concurrency?

Whether one operation happens before another operation is the key to defining what concurrency means…

In fact if we simply describe this as:

• That two operations are concurrent if neither happens before the other
• And that is neither knows about the other

Thus, whenever you have two operations A and B, there are 3 possibilities…

1. Either A happened before B
2. B happens before A
3. A and B are concurrent…

What we require is an algorithm to tell us whether two operations are concurrent or not.🤔

• If one operation happened before the other
  • The later operation should overwrite the earlier operation
• But..
  • If the operations are concurrent we have a conflict that needs to be resolved.

Concurrency, time and relativity

It may seem that it called concurrent when two operation occur at the same time.

But in fact it does not really matter whether they overlap in time.

• This is because of the clocks in distributed systems! 🕣🕗🕔🕙🤪
• It is actually difficult to tell whether something has happened at exactly the same time

P.S. I will be covering this subject more in depth in later blogs.

Time for physics…

For defining concurrency, exact time does not matter.

• We simply call two operations concurrent if they are both unaware of each other
• Regardless of the physical time of which they occurred
• Some people may connect this principle to the special theory of relativity in physics 👨‍🔬
  • Which introduces the idea that information cannot travel faster than the speed of light
• Consequently two events that occur some distance apart
  • Cannot possibly affect each other
    • If the time between the event is shorter
      • Than the time it takes light to travel the distance between them

In computer system two operations might be concurrent even though the speed of light, within principle allows one operation to affect the other.

For example:

• If the network was slow or interrupted at the time
• Two operations can occur some time apart and still be concurrent
• Because network problems prevented one operation from being able to know about the other

In my next blog post, I will be detailing the capturing of happen-before relationship into algorithm as the author Martin Kleppman in Designing Data-Intensive Applications describes, where we can tell whether two operations are concurrent.

📚 Further Reading & Related Topics

If you’re exploring concurrency and event ordering in distributed systems, these related articles will provide deeper insights:

• Distributed Data-Intensive Systems: Logical Log Replication – Learn how logical logs help maintain consistency across distributed databases, complementing the concept of event ordering.

• Resolving Write Conflicts in Distributed Data-Intensive Systems – Understand different techniques for handling concurrency conflicts in distributed environments, reinforcing the happened-before relationship.