Architecture scenarioHard~12 min

Interview question

How would you use EF Core rowversion to prevent lost updates in an API?

Handle EF Core rowversion concurrency conflicts in an API

Explains optimistic concurrency with EF Core rowversion tokens, API conflict responses, and safe retry boundaries.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

For a SQL Server-backed API, I map a rowversion column as an EF Core concurrency token and encode it as an HTTP ETag. An update requires If-Match; the API decodes that value and supplies it as the original concurrency token. EF includes it in the update predicate, and SaveChangesAsync throws DbUpdateConcurrencyException when another write has changed the row. A missing precondition and a stale precondition get deliberate HTTP responses instead of silently becoming last-write-wins.

Full answer below

Practice focus

Optimistic concurrency, rowversion, concurrency tokens, DbUpdateConcurrencyException, conflict responses, and retry behavior.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
Lost updates are easy to miss in normal CRUD demos. This drill connects SQL rowversion behavior to the API contract users actually experience.
For a SQL Server-backed API, I map a rowversion column as an EF Core concurrency token and encode it as an HTTP ETag. An update requires If-Match; the API decodes that value and supplies it as the original concurrency token. EF includes it in the update predicate, and SaveChangesAsync throws DbUpdateConcurrencyException when another write has changed the row. A missing precondition and a stale precondition get deliberate HTTP responses instead of silently becoming last-write-wins.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
The implementation keeps transport and persistence responsibilities clear. The ETag is opaque to the client, parsed strictly, and never treated as authorization. Depending on the endpoint, a missing If-Match can produce 428 Precondition Required, while a mismatch commonly produces 412 Precondition Failed with a safe current representation or reload path. I attach the submitted token as the original value and catch only the concurrency exception around the save; tenant, ownership, validation, and database constraints still protect their separate invariants.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
The conflict response follows the business operation. A preference may allow an explicit overwrite after reload, while inventory, approvals, and financial state need reconciliation rather than an automatic retry of stale intent. I test two real relational contexts updating the same row and verify the generated update predicate, because an in-memory provider cannot prove rowversion behavior. Conflict telemetry is grouped by workflow: a persistently high rate may mean the edit boundary or user interaction needs redesign, not that the API needs a bigger retry loop.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Using last-write-wins for important updates.
Catching concurrency exceptions and retrying every update blindly.
Only checking the version in the frontend.
Assuming one rowversion protects a multi-row invariant.

Red flagsCandidateRed flagsSignals that an interviewer may treat as risky.Open details

Details

Cannot explain why zero rows affected means conflict.
Has no API response plan for conflicts.
Does not know what EF Core concurrency tokens do.
Ignores user experience and auditability.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

When is automatic retry safe?
How would you encode a rowversion in an API response?
What if the update touches multiple related rows?

Continue practice

Move to the linked follow-up, next path step, prerequisite, or deeper variant.

1 linked

Go deeper

Practice the next layer of the same subject.

Optimistic Concurrency

Practice route

Read core answer Review checklist Follow-up prompts Track progress

Finished this drill?

Practice freely. Sign in only when you want to save completion, confidence, notes, or bookmarks.

New to Aporeon? Create account

Drill details

Share the question with a concise Core-answer excerpt and invite other developers to add their perspective.

Was this drill useful?

Help improve the interview library.

Found this answer useful?

Say thanks with a standalone, one-time $5 contribution. No account required.

No subscription or perks.Choose another amount

Human editorial direction

Aporeon is shaped by Aleksandar Tomovski, a software developer with experience on both sides of technical interviews. Content is reviewed for accuracy, natural spoken delivery, useful depth, and honest trade-offs.

About the creator Editorial standards

Opening drill

Architecture scenarioHard~12 min

Interview question

How would you use EF Core rowversion to prevent lost updates in an API?

Handle EF Core rowversion concurrency conflicts in an API

Explains optimistic concurrency with EF Core rowversion tokens, API conflict responses, and safe retry boundaries.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Full answer below

Practice focus

Optimistic concurrency, rowversion, concurrency tokens, DbUpdateConcurrencyException, conflict responses, and retry behavior.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
Lost updates are easy to miss in normal CRUD demos. This drill connects SQL rowversion behavior to the API contract users actually experience.
For a SQL Server-backed API, I map a rowversion column as an EF Core concurrency token and encode it as an HTTP ETag. An update requires If-Match; the API decodes that value and supplies it as the original concurrency token. EF includes it in the update predicate, and SaveChangesAsync throws DbUpdateConcurrencyException when another write has changed the row. A missing precondition and a stale precondition get deliberate HTTP responses instead of silently becoming last-write-wins.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
The implementation keeps transport and persistence responsibilities clear. The ETag is opaque to the client, parsed strictly, and never treated as authorization. Depending on the endpoint, a missing If-Match can produce 428 Precondition Required, while a mismatch commonly produces 412 Precondition Failed with a safe current representation or reload path. I attach the submitted token as the original value and catch only the concurrency exception around the save; tenant, ownership, validation, and database constraints still protect their separate invariants.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
The conflict response follows the business operation. A preference may allow an explicit overwrite after reload, while inventory, approvals, and financial state need reconciliation rather than an automatic retry of stale intent. I test two real relational contexts updating the same row and verify the generated update predicate, because an in-memory provider cannot prove rowversion behavior. Conflict telemetry is grouped by workflow: a persistently high rate may mean the edit boundary or user interaction needs redesign, not that the API needs a bigger retry loop.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Using last-write-wins for important updates.
Catching concurrency exceptions and retrying every update blindly.
Only checking the version in the frontend.
Assuming one rowversion protects a multi-row invariant.

Red flagsCandidateRed flagsSignals that an interviewer may treat as risky.Open details

Details

Cannot explain why zero rows affected means conflict.
Has no API response plan for conflicts.
Does not know what EF Core concurrency tokens do.
Ignores user experience and auditability.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

When is automatic retry safe?
How would you encode a rowversion in an API response?
What if the update touches multiple related rows?

Continue practice

Move to the linked follow-up, next path step, prerequisite, or deeper variant.

1 linked

Go deeper

Practice the next layer of the same subject.

Optimistic Concurrency

How would you use EF Core rowversion to prevent lost updates in an API?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue practice

Go deeper

How would you use EF Core rowversion to prevent lost updates in an API?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue practice

Go deeper