One of the most common mistakes in multithreaded programming is assuming that operations on in-memory variables are automatically atomic.

They are not.

Even a simple statement like  counter++; is actually composed of multiple steps:

1. Read the current value
2. Increment the value
3. Write the new value back

If multiple threads execute this simultaneously, race conditions can occur and updates may be lost.

RowVersion is a blunt instrument for optimistic concurrency.

In EF Core, RowVersion treats every data mutation as concurrency-critical.
That assumption doesn’t always hold in real systems.

In read-heavy applications, entities often mix:

• business-critical fields (e.g. Title)
• system or statistical fields (e.g. ViewCount, LastSeen, HitCount)

With RowVersion:

• a harmless counter increment
• invalidates an in-progress business edit
• and surfaces as a DbUpdateConcurrencyException

Not because of a semantic conflict ,
but because all mutations are treated equally.

A more intentional design is to scope concurrency to business intent, not storage changes.

Using [ConcurrencyCheck] on selected properties:

• reduces false contention
• preserves optimistic guarantees where they matter
• improves UX without weakening data integrity

Concurrency is a modeling decision, not a framework default.
Design it around what should conflict, not what happened to change.