¿En qué punto sustituyen los equipos una tabla de cola de PostgreSQL por un message broker, y qué lo desencadenó?

Pregunta abierta

La documentación de PostgreSQL indica que con SKIP LOCKED se omiten las filas seleccionadas que no se pueden bloquear de inmediato, y que, aunque esto da una vista inconsistente inadecuada para trabajo general, puede usarse para evitar la contención de bloqueos con varios consumidores que acceden a una tabla que actúa como cola. Las guías de diseño de este wiki, incluida la del planificador de trabajos, recomiendan por ello empezar con una tabla de cola y aplazar un message broker hasta que las mediciones lo exijan. Lo que falta es un registro de cuándo llegó esa exigencia. ¿Qué sistemas que empezaron con una tabla de cola pasaron después a un broker, y cuál fue el desencadenante: la antigüedad del trabajo listo más antiguo, las esperas de bloqueo o las tuplas muertas por actualizaciones frecuentes, la necesidad de fan-out hacia varios consumidores, la retención de eventos para su repetición, un segundo lenguaje o servicio que necesitaba la misma cola, o simplemente la preferencia operativa de una persona nueva en el equipo? ¿Con qué volumen de trabajos y número de filas se produjo el cambio, y se ajustó primero la variante de tabla (particionado, archivado de trabajos completados, ajuste de autovacuum) o se sustituyó directamente? Igual de útil es la otra mitad: sistemas que conservaron la tabla de cola durante años, con sus volúmenes, y qué hicieron en lugar de migrar. El conjunto de guías descansa en el supuesto de que la tabla basta durante mucho tiempo; ese supuesto debería contrastarse con casos reales.

Qué contiene una respuesta útil

La carga de trabajo: trabajos por día, promedio y pico, número de filas conservadas en la tabla, número de procesos trabajadores y tipos de trabajo. La versión de la base de datos y si se usó SKIP LOCKED, bloqueos consultivos (advisory locks) o una activación por LISTEN/NOTIFY. El desencadenante del cambio, enunciado como un síntoma observado junto con la medición que lo mostró, no como una preocupación general. Si se probó primero el ajuste de la variante de tabla y qué cambió. El broker elegido, el enfoque de migración (escritura doble, corte directo, por tipo de trabajo), y qué se volvió más difícil después (encolado transaccional junto con el cambio de negocio, visibilidad sobre el historial de trabajos). Para los sistemas que no cambiaron, las mismas cifras de carga de trabajo y las mitigaciones usadas. Las respuestas deben indicar cómo se obtuvieron las cifras, ya que una métrica de antigüedad de cola que nunca se registró no puede haber sido el desencadenante.