Imagina esto: eres desarrollador en una empresa de servicios de pago. En pagos, cada transacción debe procesarse exactamente una vez. Son las 3 de la madrugada, las alertas explotan porque ciertos jobs de cron están ejecutando transacciones repetidas, y estás mirando bloqueos de Redis que se supone evitarían el problema. Te suena familiar
No acabamos enviando dinero veinte veces, pero el problema fue similar. Esta es la historia de cómo pasamos de un bloqueo distribuido con Redis complejo y frágil a una solución centrada en la base de datos, simple y robusta, y por qué probablemente tú también deberías abandonar esos candados distribuidos.
El desastre del candado Redis de 2025
El contexto: teníamos una plataforma de pruebas automatizadas donde las personas desarrolladoras subían especificaciones OpenAPI y nuestros workers generaban suites de test en segundo plano. Parecía sencillo. No lo era.
Funcionaba así: alguien subía una especificación con 50 endpoints, creábamos 50 tareas pendientes en la base de datos, múltiples instancias competían por procesarlas y, como resultado, aparecían suites duplicadas y carreras por los mismos elementos.
La solución inicial fue un bloqueo a nivel de usuario en Redis usando operaciones de tipo setnx para asegurar que un único worker procesara las tareas de un usuario a la vez. En el papel sonaba bien. En producción fue otra historia.
Problema de candados fantasma
Cuando un job fallaba o se caía, dejaba un bloqueo huérfano en Redis. Las tareas de la persona usuaria quedaban congeladas de forma indefinida. Había que limpiar manualmente, algo tan entretenido como alinear píxeles en CSS en la madrugada.
El ballet de la condición de carrera
Dos workers consultaban si existían tareas pendientes para un usuario y competían por el mismo bloqueo. Uno lo obtenía, otro no, pero el ganador a veces empezaba a procesar elementos que ya estaban siendo tratados por otra instancia por desincronización entre lectura y bloqueo. Sutil, intermitente y difícil de reproducir.
El síndrome de debería funcionar
La idea sonaba razonable. El bloqueo por usuario debería prevenir el procesado duplicado. Aun así, seguíamos generando suites duplicadas y los reportes crecían más rápido que nuestras correcciones.
La epifanía de la base de datos
Entonces surgió la pregunta obvia: por qué usar Redis si nuestra base de datos ya resuelve concurrencia. PostgreSQL lleva décadas lidiando con bloqueos, aislamiento y consistencia.
La solución fue directa: reclamar una tarea con una actualización condicional en la tabla de tareas, cambiando el estado de pendiente a en proceso solo si seguía en pendiente, y usar el conteo de filas afectadas para saber si la reclamación fue exitosa. Si dos workers compiten, solo uno actualiza, el otro no. Atomicidad real gracias a las propiedades ACID.
Por qué funciona
Cuando dos procesos intentan reclamar la misma tarea, la base de datos aplica bloqueo de fila y aislamiento. Uno actualiza estado a en proceso y obtiene una fila afectada. El otro no altera nada porque la fila ya no cumple la condición de pendiente. Sin llamadas a Redis, sin limpieza de candados, sin temporizadores, sin lógica compleja.
La simplicidad gana
El bucle principal pasó a ser aburrido en el mejor sentido: listar tareas pendientes, intentar reclamarlas con una actualización condicional y, si no se pudo, continuar. Nada de servicios adicionales ni dependencias que alimentar.
El nuevo reto: acaparadores de recursos
A la semana apareció un caso real de justicia de recursos. Una empresa subió una especificación con mil endpoints. Todas las instancias se pusieron a pelear por ese conjunto, ignorando a quienes tenían tres o cinco endpoints. Resultado: personas usuarias con trabajos pequeños esperando mucho tiempo por culpa del gigante.
La solución de equidad
Aplicamos lo más simple y efectivo primero: limitar la concurrencia por usuario. Por ejemplo, máximo dos tareas en proceso simultáneamente por persona usuaria. Antes de reclamar una tarea, contamos cuántas tiene en proceso y, si alcanzó el límite, saltamos a la siguiente. Con ello equilibramos el uso, evitando que una sola cuenta acapare los workers.
Otras variantes
Consulta única con equidad. Es posible combinar en una sola operación la verificación del límite por usuario y el cambio de estado. Esto reduce viajes a la base de datos, pero complica el diagnóstico cuando algo falla.
Round robin por usuario. Otra opción es ordenar las tareas pendientes priorizando a quienes tienen menos tareas en curso y, en segundo lugar, por fecha de creación. Así maximizas la justicia entre inquilinos.
Priorización temporal. Puedes priorizar usuarios según la fecha de última atención para favorecer a quien lleva más tiempo sin recursos. Suele ser útil en grandes plataformas, quizá excesivo para la mayoría.
Lecciones clave
La base de datos es más lista de lo que crees. Lleva décadas resolviendo concurrencia. Usa sus garantías de atomicidad y aislamiento en lugar de reinventar bloqueos distribuidos.
La complejidad es un bug. Cada línea extra de bloqueo en Redis añade puntos de fallo: tiempo de red, limpieza de llaves, condiciones de carrera interservicio y gestión de memoria. Reducir piezas reduce incidencias.
La equidad no es opcional en entornos multi inquilino. Si diferentes usuarios compiten por recursos, define límites, prioridades y políticas desde el inicio.
Empieza simple y optimiza. Mejor dos pasos claros y trazables que una consulta críptica difícil de depurar a las 3 de la madrugada.
Realidad de rendimiento
Enfoque con base de datos: no consume memoria en Redis, se apoya en la infraestructura existente, ofrece garantías ACID y añade cierta carga al motor por la verificación de equidad. Enfoque con Redis: operaciones en memoria muy rápidas, pero más piezas que mantener, llamadas de red que pueden fallar y complejidad para la vida y muerte de los candados.
Cuándo usar cada uno
Usa atomicidad en la base de datos si las tareas ya viven ahí, si quieres consistencia fuerte y si deseas reducir complejidad de infraestructura. Considera bloqueos distribuidos cuando necesites coordinar entre múltiples bases, orquestaciones largas con muchos pasos o ya tengas un stack operado por un equipo experto en ese patrón.
Conclusión
Reemplazamos decenas de líneas de lógica de bloqueo en Redis por unas pocas operaciones SQL y eliminamos los duplicados de procesamiento. A veces, la mejor ingeniería es la solución simple que siempre ha estado delante de ti. Confía en tu base de datos.
Cómo te ayuda Q2BSTUDIO
En Q2BSTUDIO diseñamos y construimos aplicaciones a medida y software a medida escalables, resilientes y orientadas a resultados, combinando buenas prácticas de concurrencia, observabilidad y arquitectura limpia. Somos especialistas en inteligencia artificial aplicada, ia para empresas, agentes IA, ciberseguridad, servicios cloud aws y azure, servicios inteligencia de negocio y power bi, para que tu plataforma sea más rápida, segura y preparada para crecer. Si necesitas un partner para llevar tu backend a nivel producción, consulta nuestro servicio de desarrollo de aplicaciones y software multiplataforma. Y si buscas despliegues elásticos y resiliencia con infraestructura administrada, descubre nuestros servicios cloud en Azure y AWS. Diseñamos soluciones que evitan bloqueos innecesarios, priorizan la equidad entre inquilinos y aprovechan al máximo tu base de datos, para que tu producto avance sin fricción.