¿Qué es una race condition? Dame un ejemplo real en un backend y contame cómo la prevenís.

Una race condition ocurre cuando el resultado depende del orden o el momento en que se ejecutan operaciones concurrentes sobre un recurso compartido, y ese orden no está controlado.

Ejemplo típico: control de stock con el patrón leer-modificar-escribir.

stock = SELECT stock FROM productos WHERE id = 1;  -- ambos leen 1
if stock > 0:
    UPDATE productos SET stock = stock_leido - 1 WHERE id = 1;  -- ambos venden

Dos requests leen stock = 1 al mismo tiempo, ambos ven que hay disponible y se venden dos unidades de una sola.

Cómo prevenirla:

• Operación atómica en la base:

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

  y verificar las filas afectadas. Es la solución más simple y robusta.
• Bloqueo pesimista: SELECT ... FOR UPDATE dentro de una transacción, cuando la lógica es compleja.
• Constraints: UNIQUE o CHECK (stock >= 0) como última red de seguridad.
• En memoria: mutex/locks o estructuras atómicas (AtomicInteger, ConcurrentHashMap), siempre minimizando la sección crítica.
• Sistemas distribuidos: locks distribuidos con cuidado (TTL, fencing tokens) o, mejor, diseñar para que la base o una cola serialicen las operaciones.

Testing: son difíciles de reproducir; ayudan los tests de carga concurrentes, los race detectors (por ejemplo go test -race) y revisar todo patrón check-then-act.

También tiene impacto en seguridad: las condiciones TOCTOU permiten canjear un cupón varias veces o superar límites de saldo, por lo que conviene contemplarlas en code review.

Confundir race condition con deadlock. Proponer solo un lock en memoria cuando la app corre en varias instancias. Olvidar que una transacción con aislamiento READ COMMITTED no evita por sí sola el problema de leer-modificar-escribir.