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.

Carregando publicação patrocinada...
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.