Implement user creation that remains correct when two requests race to register the same normalized email.

• Normalize email consistently before persistence.
• Keep the database unique index as the authority.
• Classify the exact expected constraint, not every DbUpdateException.
• Let unrelated database failures propagate to normal error handling.

I attempt the insert and catch DbUpdateException only when a provider-aware classifier identifies the expected unique index. This keeps the endpoint portable at the application boundary while the infrastructure classifier understands SQL state or provider error codes. An existence check alone is never enough because it leaves a race window.

public static async Task<CreateUserResult> CreateUserAsync(
    AppDbContext db,
    IDatabaseErrorClassifier databaseErrors,
    CreateUser request,
    CancellationToken cancellationToken)
{
    var normalizedEmail = EmailNormalizer.Normalize(request.Email);
    var user = User.Create(request.Email.Trim(), normalizedEmail);

    db.Users.Add(user);

    try
    {
        await db.SaveChangesAsync(cancellationToken);
        return CreateUserResult.Created(user.Id);
    }
    catch (DbUpdateException exception)
        when (databaseErrors.IsUniqueConstraint(
            exception,
            "ux_users_normalized_email"))
    {
        return CreateUserResult.EmailAlreadyExists();
    }
}

The successful path is one insert. Under contention, the unique index serializes the business key and one writer fails predictably. The provider-specific classifier should have focused integration tests against an isolated test database or container because in-memory providers do not reproduce relational constraint errors.

• Case and surrounding-space variants of one email.
• A different unique constraint fails on the same entity.
• The database is unavailable rather than rejecting a duplicate.
• A retry repeats the same create request.

• Run concurrent creates against an isolated relational test database.
• Verify an unrelated DbUpdateException is not converted to email conflict.
• Test all supported email normalization cases.
• Assert the unique index exists in the migration model.

• Trusting a check-then-insert sequence as race-free.
• Catching every DbUpdateException and calling it a duplicate.
• Parsing provider exception text with fragile substring matching.
• Testing uniqueness only with the EF in-memory provider.