Dos usuarios editan el mismo registro a la vez y los cambios de uno pisan los del otro. ¿Cómo lo evitás?

Es un lost update: los dos leen la versión N, cada uno guarda la suya y gana el último en escribir. Según el caso, hay varias soluciones.

Se agrega una columna version (o un updated_at) y se actualiza solo si nadie la cambió:

UPDATE productos
SET precio = :precio, version = version + 1
WHERE id = :id AND version = :version_leida;

Si la consulta afecta 0 filas, hubo un conflicto. Se devuelve 409 Conflict y el usuario recarga o se le ofrece hacer merge. En HTTP se puede exponer con ETag + If-Match, y la API responde 412 si no coincide. Los ORM lo traen incorporado, por ejemplo @Version en JPA o el concurrency token en EF Core.

SELECT ... FOR UPDATE dentro de una transacción corta. Sirve cuando la contención es alta y reintentar sale caro. Nunca hay que mantener el lock mientras el usuario piensa frente al formulario, y hay que vigilar los deadlocks: tomar los locks en orden consistente y usar timeouts.

Para contadores o stock no hace falta leer y escribir por separado:

UPDATE productos SET stock = stock - 1
WHERE id = :id AND stock > 0;

Criterio: optimista para ediciones de usuarios con pocos conflictos, pesimista para secciones críticas cortas y con mucha contención, y operaciones atómicas siempre que se puedan expresar en una sola sentencia. Subir el nivel de aislamiento (REPEATABLE READ o SERIALIZABLE) también ayuda, pero exige manejar reintentos.

Proponer solo "usar una transacción", sin entender que con READ COMMITTED el lost update sigue ocurriendo. Olvidar chequear las filas afectadas, o mantener locks pesimistas durante la interacción del usuario.