¿Usar Postgres como cola de trabajos? 🚀

Construir una cola con Go y PostgreSQL no es un mito.

📌 Cuando tu web manda emails, procesa imágenes o reintenta APIs, esos flujos no deben estar dentro del request del usuario. La latencia y la posibilidad de fallos lo convierten en tareas que deben ser background.

🧐 El gran dilema: ¿Redis, RabbitMQ o Postgres? El artículo demuestra que Postgres, con sus transacciones, row‑locks y LISTEN/NOTIFY, ya es una solución robusta y ligera.

🔑 Puntos clave: • Almacena cada trabajo en una tabla “swig jobs” con JSONB para payload. • Claim concurrente sin duplicados: “FOR UPDATE SKIP LOCKED”. • Wake workers vía NOTIFY, evitando polling continuo. • Elección de líder con advisory locks, sin necesidad de ZooKeeper. • Transacciones de creación que garantizan que el job y el dato de la app se crean juntos.

🚀 Ejemplo rápido de registro y ejecución: - Registrar un `EmailWorker` con su estructura JSON. - Encolar con `AddJob` dentro de una transacción que también inserta el usuario. - Worker goroutine consume con `Process`, lanza `SendEmail` y marca completado.

💡 El resultado: una cola simple, transaccional, confiable y sin servicios externos.

🔄 El reto es la idempotencia: si un worker falla entre el send y el update, el job vuelve a la cola y podemos reintentar sin duplicados.

🤔 ¿Cómo gestionas los job queues en tu stack? ¿Postgres o otras soluciones? ¿Qué características buscas?

#DesarrolloBackend, #DesarrolloFullStack, #ArquitecturaDeSoftware, #IngenieriaDeSoftware