Quando as equipes trocam uma tabela de fila no PostgreSQL por um message broker, e o que motivou a mudança?

Pergunta em aberto

A documentação do PostgreSQL afirma que, com SKIP LOCKED, as linhas selecionadas que não podem ser bloqueadas imediatamente são ignoradas. Segundo ela, isso produz uma visão inconsistente, inadequada para uso geral, mas pode ser usado para evitar contenção de locks quando vários consumidores acessam uma tabela com comportamento de fila. Os guias de design desta wiki, incluindo o do agendador de jobs, recomendam por isso começar com uma tabela de fila e adiar o message broker até que as medições o exijam. Falta um registro de quando essa necessidade surgiu. Quais sistemas que começaram com uma tabela de fila migraram depois para um broker, e qual foi o gatilho: a idade do job pronto mais antigo, esperas por locks ou dead tuples causadas por atualizações frequentes, a necessidade de fan-out para vários consumidores, a retenção de eventos para replay, uma segunda linguagem ou serviço que precisava da mesma fila, ou simplesmente a preferência operacional de um novo integrante da equipe? Com que volume de jobs e quantidade de linhas a mudança aconteceu, e a variante com tabela foi ajustada antes (particionamento, arquivamento de linhas concluídas, ajuste do autovacuum) ou substituída diretamente? Igualmente útil é a outra metade: sistemas que mantiveram a tabela de fila por anos, com seus volumes, e o que fizeram em vez de migrar. O conjunto de guias parte do pressuposto de que a tabela basta por muito tempo; esse pressuposto precisa ser confrontado com casos reais.

O que uma resposta útil contém

A carga de trabalho: jobs por dia, em média e no pico, quantidade de linhas mantidas na tabela, número de processos worker e tipos de job. A versão do banco de dados e se foi usado SKIP LOCKED, advisory locks ou um wake-up via LISTEN/NOTIFY. O gatilho da troca, descrito como um sintoma observado, com a medição que o evidenciou, e não como uma preocupação genérica. Se o ajuste da variante com tabela foi tentado antes e o que ele mudou. O broker escolhido, a abordagem de migração (dual-write, cut-over, por tipo de job) e o que ficou mais difícil depois (enfileirar de forma transacional junto com a alteração de negócio, visibilidade do histórico de jobs). Para sistemas que não trocaram, os mesmos números de carga e as mitigações usadas. As respostas devem dizer como os números foram obtidos, pois uma métrica de idade da fila que nunca foi registrada não pode ter sido o gatilho.