A decisão de manter Go e migrar só o front pra leptos faz sentido dado o problema: refazer a implementação de DB da lib Rust do WhatsApp pra suportar centenas de sessões custaria mais do que vale. E já pensar em leptos CSR visando Tauri depois é uma jogada inteligente, a compilação pro desktop fica bem natural. Como você está gerenciando o ciclo de vida das sessões WhatsApp no Redis quando a sessão fica inativa por muito tempo?
Não gerencio, a não ser que desconecte do whatsapp ele fica lá enquanto o servidor estiver ativo, alem de subir junto com o boot. Apenas se o admin da sessão desconectar que ele realmente é tirado do redis e fica só com as credenciais em standby no postgres (criptografado claro) para o proximo start tentar reconexão sem qrcode. Esse é justamente o motivo de eu manter o backend go que já tá bem otimizado, o redis acaba mantendo todas as sessões em memoria, o que é +/- 50mb por sessão.
50mb por sessão no Redis é bem razoável considerando que você elimina a reconexão com QR code. A parte inteligente é manter as credenciais no Postgres como fallback: você perde a sessão em memória mas mantém a capacidade de reconexão automática. Esse padrão de Redis como cache mais banco relacional como fonte de verdade resolve bem o trade-off entre custo de memória e latência em sessões de longa duração.
Eu sinceramente motivado pelas postagens de um outro usuario aqui do tabnews tô pensando em testar uma unlogged table do postgres no lugar do redis pra ver se consigo reduzir o uso de memoria enquanto joga a porrada inteira no postgres (unlogged tem througput alto por não ter WAL) se a latência não for muito mais alta para o uso é uma boa troca mas claro que tem que testar pra ver se o tempo resposta ainda tá bom e não tem um atraso muito alto na entrega de webhooks (notify do postgres) a ideia é realmente passar toda a responsabilidade da stack pro postgres sem cache, sem filas só o elefante.