Escolhendo uma tecnologia de fila com Postgres

• Filas com Postgres são boas, mas não são populares principalmente por causa da percepção geral de que outras tecnologias de fila oferecem maior escalabilidade
• Empresas como a webapp.io escolheram filas com Postgres por valorizarem mais a simplicidade operacional, a facilidade de manutenção e a familiaridade do que a escalabilidade
• Componentes de uma tecnologia de fila com Postgres
  • notificar e escutar novos trabalhos (pub/sub) e exclusão mútua (row locks)
  • esses dois recursos estão disponíveis desde o Postgres 9.5, lançado em 2016
• O autor rebate a visão comum na indústria de que usar Postgres dessa forma seria um “hack” e argumenta que Postgres não é uma tecnologia de fila inferior
• Redis, Apache Kafka, RabbitMQ e Amazon SQS têm sido escolhidos como ferramentas de fila para lidar com trabalhos de longa duração
• O autor critica a obsessão do setor de tecnologia com “escala” e critica o sacrifício da simplicidade, da facilidade de manutenção e da redução da carga cognitiva dos desenvolvedores
• Ao tomar decisões técnicas, a sugestão do autor é considerar as tecnologias que você já usa e entende bem
• Ele recomenda escolher a “tecnologia chata” que já está em uso e é bem compreendida
• Introdução ao conceito de “construir uma rota de fuga”, que significa que o código da aplicação para processamento de tarefas deve ser indiferente à fila
• O autor conclui incentivando outras pessoas a considerar a tecnologia de fila com Postgres e a adotar a “tecnologia chata” como escolha padrão

[GN⁺]

Comentários do Hacker News

• A simplicidade, durabilidade e tolerância a falhas do Kafka são reconhecidas, mas sua natureza distribuída pode adicionar complexidade na maioria dos casos de uso.
• Filas com Postgres podem substituir filas com Redis, mas não podem substituir filas com SQS.
• O Postgres foi usado para processar mais de 400 milhões de eventos desde que o sistema entrou em operação, lidando com cerca de 1 milhão de eventos por dia.
• Usar uma tabela comum com SELECT FOR UPDATE SKIP LOCKED é uma abordagem simples que funciona em todos os frameworks ORM/Query DSL.
• A principal desvantagem de usar LISTEN/NOTIFY para utilizar o PostgreSQL como barramento pub/sub é que LISTEN é um recurso de sessão, portanto não é compatível com pool de conexões em nível de instrução.
• Usar o Postgres como fila de aplicação traz a vantagem da transacionalidade, e tarefas assíncronas agendadas se beneficiam disso.
• O Postgres pode escalar para filas, mas configurar o SQS ou outra stack de filas na AWS, GCP ou Azure é mais simples e foi feito para esse propósito.
• O Postgres executou benchmarks a 1200 jobs/s em uma instância de CI do GitHub, com escala até 5000 jobs/s por meio de workers adicionais.
• O Postgres com Oban, do Elixir, foi usado para processar diariamente de centenas de milhares a milhões de jobs, e as semânticas transacionais em torno dos trabalhos em segundo plano se mostraram convenientemente comprovadas.
• Uma implementação que processou 47M de jobs destaca os benefícios do armazenamento durável com SKIP LOCKED para VACUUM, jobs atrasados, retries, atualizações de estado e índices para implementar padrões caros como "pelo menos uma vez".