Flujos de registro bajo alta concurrencia

Estos flujos corrían sobre portales donde los usuarios se registraban a sorteos bajo presión de tiempo. La misma entrega tenía que aguantar ráfagas de tráfico mientras evitaba entradas duplicadas o inconsistentes.

El riesgo no era solo la carga. El sistema también tenía que frenar registros duplicados, envíos repetidos, combinaciones de datos inválidas y casos límite creados por peticiones concurrentes.

Como el stack incluía WordPress y bases de datos existentes, las defensas tenían que funcionar en frontend, backend y persistencia, no en una sola capa.

Construí el flujo de registro spec-first: definí las reglas de deduplicación, idempotencia y persistencia antes de escribir código, así que los casos límite de concurrencia aparecieron en la spec y no en producción.

Implementé validación a ambos lados de la petición, deduplicación con restricciones de BBDD, idempotencia en el camino de escritura y rate limiting en la entrada — de forma que los envíos concurrentes y repetidos no generaran entradas duplicadas, pero los reintentos legítimos del mismo usuario siguieran funcionando.

El objetivo era rechazar registros malos cuanto antes, mantener estrictas las reglas de persistencia y dejar suficiente señal en producción para depurar incidentes rápido.

Los flujos de sorteos pasaron de validación ad hoc a caminos de registro controlados con deduplicación, escrituras idempotentes, rate limiting y señales operativas más claras.

Eso redujo registros inconsistentes, entradas repetidas y limpieza manual durante ventanas de alta demanda, manteniendo a la vez los reintentos legítimos del mismo usuario funcionando.