Concurrency happens when two users change the same row at the same time.

Think of this like two people try to book the last seat for a show

• User A selects the seat at 10:01.

• User B selects the same seat at 10:02.

• Both hit "Book" around the same time.

Only one can win.
This is concurrency: two people acting on the same data, overlapping in time.

When does it happen?

• Two tabs of your app edit the same item.

• Two services update the same record.

• A user edits an old page and clicks Save after someone else already saved.

It is common in apps with many users.

When do we need to handle it?

• When losing another person’s change is not okay.

• Orders, money, stock count, booking seats, important text fields.

When is it not necessary?

• Data that can be rebuilt.

• Logs, caches, or places where "last save wins" is fine.

• Solo tools where only one person edits.

How EF Core helps (the simple idea)

EF Core uses optimistic concurrency by default.

• We do not lock the row while reading.

• We add a special field called a concurrency token (most common: rowversion).

• On save, EF checks if that token changed.

• If it changed, EF throws DbUpdateConcurrencyException.
  That means: "Somebody else changed this first. Decide what to do."

This avoids silent overwrites.

The easy, safe setup (SQL Server)

Step 1: Add a rowversion column in your model

public class Post
{
public int Id { get; set; }
public string Title { get; set; } = "";
public string Content { get; set; } = "";
// EF Core will treat this as a concurrency token
[Timestamp] // or configure via Fluent API
public byte[] RowVersion { get; set; } = Array.Empty<byte>();
}

Fluent API (optional alternative):

modelBuilder.Entity<Post>()
.Property(p => p.RowVersion)
.IsRowVersion();

That’s it. EF will now include RowVersion in the WHERE clause of the UPDATE.

What happens under the hood?

EF Core runs an update like this:

UPDATE Posts
SET Title = @p1, Content = @p2
WHERE Id = @id AND RowVersion = @originalRowVersion;

-- If 0 rows updated => someone else changed it => throw

EF Core example

try
{
  await context.SaveChangesAsync();
  return Results.Ok("Saved");
}

catch (DbUpdateConcurrencyException)
{
  return Results.Conflict("Someone else changed this. Please refresh.");
}

This simple pattern detects the conflict. Now let’s resolve it.

Three simple ways to resolve a conflict

Pick one based on your app’s rules.

1) Store Wins (refresh, show latest, let user edit again)

This is the safest default for text fields.

try
{
    await context.SaveChangesAsync();
}
catch (DbUpdateConcurrencyException ex)
{
    foreach (var entry in ex.Entries)
    {
        var dbValues = await entry.GetDatabaseValuesAsync();

        if (dbValues is null)
        {
            // Someone deleted it
            entry.State = EntityState.Detached;
        }
        else
        {
            // Load latest values from DB into the entity
            entry.OriginalValues.SetValues(dbValues);
            entry.CurrentValues.SetValues(dbValues);
            entry.State = EntityState.Unchanged;
        }
    }

    // Tell the user "Data changed. Please try again."
    throw; // or return a 409/Conflict
}

Why it’s good:
No one loses data. The user sees the latest copy and tries again.

2) Client Wins (force your changes to overwrite)

Use only when your update must override. Be careful.

try
{
    await context.SaveChangesAsync();
}
catch (DbUpdateConcurrencyException ex)
{
    foreach (var entry in ex.Entries)
    {
        // Accept that DB has changed; update our Original to DB values,
        // so the next Save will succeed and overwrite
        var dbValues = await entry.GetDatabaseValuesAsync();
        if (dbValues is not null)
        {
            entry.OriginalValues.SetValues(dbValues);
        }
    }

    await context.SaveChangesAsync(); // force overwrite now
}

Warning: This can erase someone else’s change.

3) Merge (pick field by field)

Great for rich text or forms. Show "Yours vs Theirs".

try
{
    await context.SaveChangesAsync();
}
catch (DbUpdateConcurrencyException ex)
{
    var entry = ex.Entries.Single();
    var dbValues = await entry.GetDatabaseValuesAsync();
    var clientValues = entry.CurrentValues;

    if (dbValues is null)
    {
        // Deleted by someone else
        entry.State = EntityState.Detached;
        throw;
    }

    // Example rule:
    // Keep my Title, but keep DB Content (just as a demo)
    clientValues["Title"]   = clientValues["Title"];
    clientValues["Content"] = dbValues["Content"];

    // Update Original to DB so next save passes
    entry.OriginalValues.SetValues(dbValues);

    await context.SaveChangesAsync();
}

Tip: In a UI, show both versions and let the user choose.

How to handle Web APIs (disconnected clients)

When you attach a DTO, you must set the original RowVersion, or EF can’t detect conflicts.

// dto includes Id, Title, Content, RowVersion
var post = new Post
{
    Id = dto.Id,
    Title = dto.Title,
    Content = dto.Content
};

context.Attach(post);

// This is key: tell EF what the original token was
context.Entry(post).Property(p => p.RowVersion).OriginalValue = dto.RowVersion;

// Mark which fields changed
context.Entry(post).Property(p => p.Title).IsModified = true;
context.Entry(post).Property(p => p.Content).IsModified = true;

await context.SaveChangesAsync();

When you need locks (rare)

If you must block others while you work (like a money move), use a transaction and a lock hint.

await using var tx = await context.Database.BeginTransactionAsync();

var item = await context.Posts
    .FromSqlInterpolated($@"
        SELECT * FROM Posts WITH (UPDLOCK, ROWLOCK)
        WHERE Id = {id}")
    .SingleAsync();

item.Title = "Critical update";

await context.SaveChangesAsync();
await tx.CommitAsync();

Use sparingly. Locks can slow things down or deadlock.

Quick checklist

• Add RowVersion (rowversion in SQL Server; mark as [Timestamp]).

• Catch DbUpdateConcurrencyException.

• Pick a rule: Store Wins, Client Wins, or Merge.

• For APIs, set OriginalValue for the token.

• Use locks only for critical cases.

Final thoughts

Start with RowVersion and Store Wins.
Add a merge screen if users often edit the same fields.
Use locks only when you must.

Welcome you all for my first edition of the newsletter.

As a full stack developer, I often create APIs using .NET core with the following best practices.

APIs should be error free, easy to understand/maintain, secure, have reliable performance, developer friendly and much more. Without following any best practices, it is difficult to achieve all the above.

Designing efficient and maintainable APIs is crucial for the success of any software project. Here are some best practices and tips for designing APIs using .NET

• Follow RESTful Principles:

  • Example: Design resource URIs meaningfully, like /users for user-related operations and /orders for order-related actions.

• Versioning is Key:

  • Example: Ensure backward compatibility by versioning your API, such as /v1/users and /v2/users.

• Meaningful and Consistent Naming:

  • Example: Choose clear and consistent names, like GET /products for fetching products.

• Use Standard Data Formats:

  • Example: Embrace JSON for both request and response payloads to maintain consistency.

• Robust Input Validation:

  • Example: Validate user input on the server side to prevent injection attacks, ensuring data integrity.

• Effective Error Handling:

  • Example: Return detailed error messages with appropriate HTTP status codes, like 404 for resource not found.

• Authentication & Authorization:

  • Example: Implement OAuth (or JWT) for secure token-based authentication and authorize users based on roles.

• Enforce HTTPS:

  • Example: Protect data transmission by enforcing HTTPS, securing communications between clients and the server.

• Pagination & Filtering:

  • Example: Implement pagination for large datasets, like /products?page=1&pageSize=10 for a paginated product list.

• Comprehensive Documentation:

  • Example: Create detailed documentation using tools like Swagger, explaining each endpoint, request/response formats, and authentication.

Let me Introduce myself and share my story…!

I am a .NET software developer based on India (Know more about me) with 12+ years of experience and currently working Full-time as a software consultant.

I am like most traditional developers, who only work on their jobs and often come online to find solutions for technical issues or learn something which is required for my projects.

Later I was introduced to twitter where I can see lot of the developers share their coding knowledge through posts, YouTube videos and few shares about their newsletters. Even some developers creating SaaS products and promoting the same.

Now it’s very clear, I need to jump on the same bandwagon (online tech community).

I explored ways to share my technical knowledge. For example, way back in 2014 I created my first post on Medium, but I was not serious about creating posts. After a few years, I created Ghost blogs on DigitalOcean but that too involves some technical issues (I was trying to blog on sub-folder /blog) and left that idea. Tried blogspot and WordPress but not posting anything on those platforms.

I was continuing to motivate myself and learning online including Become a Social Developer! and some other articles. One fine day, I decided to stop exploring the internet for motivation and planned to create something meaningful.

💡Finally, I created my blog on Hashnode and as of now created couple of posts. Simultaneously, I share my blog posts on LinkedIn, twitter, and cross post on dev.to/medium.com.

Subscribe now