Quando um assinante (consumidor) morre, sua lista continuará crescendo até que o cliente retorne. Seu produtor pode cortar a lista (de ambos os lados) assim que atingir um limite específico, mas isso é algo que você precisaria lidar no nível do aplicativo. Se você incluir um carimbo de data/hora em cada mensagem, seu consumidor poderá agir com base na idade de uma mensagem, supondo que você tenha uma lógica de aplicativo que deseja aplicar na idade da mensagem.

Não tenho certeza de como uma mensagem malformada entraria no sistema, pois a conexão com o Redis geralmente é TCP com suas garantias de integridade. Mas se isso acontecer, talvez devido a um bug na codificação de mensagens na camada do produtor, você pode fornecer um mecanismo geral para lidar com erros mantendo uma fila por produtor que recebeu as mensagens de exceção do consumidor.

As políticas de repetição dependerão muito das necessidades do seu aplicativo. Se você precisar de 100% de garantia de que uma mensagem foi recebida e processada, considere usar transações Redis (MULTI/EXEC) para agrupar o trabalho feito por um consumidor, para garantir que um cliente não remova uma mensagem, a menos que ele completou seu trabalho. Se você precisar de reconhecimento explícito, poderá usar uma mensagem ACK explícita em uma fila dedicada ao(s) processo(s) produtor(es).

Sem saber mais sobre as necessidades do seu aplicativo, é difícil saber como escolher com sabedoria. Geralmente, se suas mensagens exigirem proteção ACID completa, você provavelmente também precisará usar transações redis. Se suas mensagens são significativas apenas quando são oportunas, as transações podem não ser necessárias. Parece que você não pode tolerar mensagens descartadas, então sua abordagem de usar uma lista é boa. Se você precisar implementar uma fila de prioridade para suas mensagens, poderá usar o conjunto classificado (os comandos Z) para armazenar suas mensagens, usando sua prioridade como valor de pontuação, juntamente com um consumidor de pesquisa.