Elegir la tecnología de colas con Postgres

• Las colas con Postgres son buenas, pero no son la opción dominante debido a la idea generalizada de que otras tecnologías de colas ofrecen mayor escalabilidad
• Empresas como webapp.io eligieron colas con Postgres porque priorizan la simplicidad operativa, la facilidad de mantenimiento y la familiaridad por encima de la escalabilidad
• Componentes de la tecnología de colas con Postgres
  • notificar y escuchar nuevos trabajos (pub/sub) y exclusión mutua (row locks)
  • estas dos funciones están disponibles desde Postgres 9.5, lanzado en 2016
• El autor rebate la percepción común en la industria de que usar Postgres de esta manera es un “hack” y sostiene que Postgres no es una tecnología de colas de segunda categoría
• Herramientas de colas como Redis, Apache Kafka, RabbitMQ y Amazon SQS han sido las elegidas tradicionalmente para procesar trabajos de larga duración
• Se critica la obsesión de la industria tecnológica con la “escala” y el sacrificio de la simplicidad, la mantenibilidad y la reducción de la carga cognitiva de los desarrolladores
• El autor propone que, al tomar decisiones tecnológicas, se considere la tecnología que ya se usa y se comprende bien
• Recomienda elegir una “tecnología aburrida” que ya esté en uso y sea bien entendida
• Se presenta el concepto de “construir una ruta de escape”, es decir, que el código de la aplicación para procesar trabajos debe ser independiente de la cola
• El autor concluye animando a otros a considerar la tecnología de colas con Postgres y a tomar como opción predeterminada una “tecnología aburrida”

[GN⁺]

Opiniones de Hacker News

• Aunque se reconoce la simplicidad, persistencia y tolerancia a fallos de Kafka, su naturaleza distribuida puede agregar complejidad en la mayoría de los casos de uso.
• Las colas de Postgres pueden reemplazar a las colas de Redis, pero no pueden reemplazar a las colas de SQS.
• Postgres se ha usado para procesar más de 400 millones de eventos desde que el sistema entró en operación, manejando alrededor de 1 millón de eventos al día.
• Usar una tabla normal con SELECT FOR UPDATE SKIP LOCKED es un enfoque sencillo que funciona en todos los frameworks ORM/Query DSL.
• La principal desventaja de usar PostgreSQL como bus pub/sub con LISTEN/NOTIFY es que LISTEN es una función de sesión, por lo que no es compatible con connection pooling a nivel de sentencia.
• Usar Postgres como cola de la aplicación ofrece beneficios transaccionales, de los que se benefician los trabajos asíncronos programados.
• Postgres puede escalar para colas, pero configurar SQS u otro stack de colas en AWS, GCP o Azure es más simple y está diseñado específicamente para ese propósito.
• Postgres ejecutó benchmarks a 1200 jobs/s en una instancia de GitHub CI y escaló a 5000 jobs/s con workers adicionales.
• Postgres con Oban de Elixir se ha usado para manejar, de forma comprobada y conveniente, desde cientos de miles hasta millones de trabajos individuales gracias a la semántica transaccional alrededor de los trabajos en segundo plano.
• Una implementación que procesó 47M trabajos destaca las ventajas del almacenamiento duradero con índices para implementar patrones costosos como SKIP LOCKED para VACUUM, trabajos diferidos, reintentos, actualizaciones de estado y "al menos una vez".