1

Fiz algo parecido para cache de sessão aqui no BloodLink. Unlogged table resolve bem o throughput, mas tem um detalhe crítico: em crash, o Postgres trunca a tabela no recovery. Para webhooks isso significa perder eventos não processados.

O NOTIFY também tem uma limitação não óbvia: se o listener não estiver conectado no momento, a mensagem some. Então a tabela funciona bem como fila, mas o NOTIFY serve melhor como sinal de 'vai buscar' do que como portador da mensagem em si.

Se o caso de uso aceita perder eventos em crash e o listener é estável, a troca por Redis faz sentido. Quanto de memória você está tentando economizar?

Carregando publicação patrocinada...
3

Interessante, no meu caso a unlogged table seria pra cache de instâncias e o notify para a entrega de webhooks, como o consumidor seria parte do meu serviço talvez faça sentido eu separar o notify do serviço principal pra ser mais estável, obrigado por esse dado. Quanto a economia de memoria pra esse caso quanto maior melhor as sessões no whatsmeow ativas se valem de websocket e para você enviar as mensagens tem que ser criptografadas com chaves especificas por contato (whatsmeow abstrai isso) então acaba que as chaves são necessarias o tempo inteiro e alguns dados da sessão também, criptografia é custosa tanto pra cpu quanto pra ram então quanto mais ram eu conseguir economizar no que tá em volta mais sessões ativas consigo sustentar, perda de eventos gerais é aceitavel, perda de mensagens não então um fluxo separado para esses eventos pode ser interessante se eu não conseguir colocar isso no postgres realmente seria necessario uma fila dedicada como rabbit ou bull pois nessa parte em específico a perda de webhook é inaceitável se fosse a perda de um webhook de qr code dá pra fazer o client pedir um status em caso de mensagem isso é irreal. Quanto ao uso do postgres pra cache de sessão, você consegue dar mais detalhes sobre?

1

Para cache de sessão, o que faço é serializar o estado da sessão (chaves, device info, o que o whatsmeow usa para reconectar) em JSONB numa tabela unlogged. Na inicialização você carrega do postgres, depois o que fica em memória é só o que está ativo naquele momento.

A vantagem de RAM vem de poder fazer lazy load: em vez de manter tudo em memória o tempo inteiro, você só carrega o que está sendo usado. Sessão inativa por X minutos pode ter estado descarregado da memória e recarregado na reconexão.

Para as chaves de criptografia por contato, é a mesma lógica: persiste no postgres, carrega sob demanda. A latência de um SELECT é aceitável comparado ao tempo de handshake que você já economizou.

3

No meu caso o lazy load da sessão não é possível já que receber mensagem é parte core do serviço o ganho é mais na criptografia por contato e manter a camada http bem leve, infelizmente nas sessões em si não tenho como economizar na ram, mas bom saber que a unlogged table é o suficiente, é literalmente dois serviços a menos já não vou usar redis e nem rabbitmq o que economiza algumas centenas de mb de ram.

1

Faz todo sentido, serviço de mensagens não tem como adiar as sessões. Mesmo que não dê pra economizar na RAM delas, eliminar Redis e RabbitMQ já é um ganho enorme em complexidade operacional, não só em memória. Dois serviços a menos pra monitorar, escalar e eventualmente falhar.