ADR-011 — Idempotencia por constraints de base de datos¶

Status: accepted (D11 del BRIEF; consumo atómico como invariante en CONSTITUTION)
Context: Conexiones 3G de salón: envíos duplicados, retries de formularios cortados y doble tap son la norma, no la excepción.
Alternatives: locks de aplicación (frágiles ante múltiples workers); idempotencia a nivel DB (elegida).
Decision: Alta de cliente idempotente por dni UNIQUE; consumo de voucher atómico por hash_token UNIQUE (inserción única de la chance). El retry de una registración cortada resuelve a caso B (ya participó), nunca a doble chance.
Consequences: La corrección no depende del comportamiento del cliente ni del número de instancias del backend; el conflicto DB se traduce a la respuesta del caso B.

Implementation Plan¶

Constraints UNIQUE (cliente.dni, chance.hash_token) + manejo del conflicto en la transacción de participación (INSERT ... ON CONFLICT / captura de duplicate key).
La transacción alta-de-cliente + chance + aceptación de bases es una sola unidad.

[ ] Test de concurrencia: N envíos simultáneos del mismo token → exactamente 1 chance.
[ ] Test: retry post-corte del alta 1b → caso B con fecha de la participación original.
[ ] Test: dos altas simultáneas del mismo DNI → un solo Cliente.