Usamos o Redis no Trello para dados efêmeros que estaríamos bem em perder. Não persistimos os dados no Redis no disco e os usamos allkeys-lru, portanto, armazenamos apenas coisas que podem ser expulsas a qualquer momento com apenas um pequeno inconveniente para os usuários (por exemplo, ver momentaneamente um status de usuário incorreto). Dito isto, damos a ele mais de 5x o espaço necessário para armazenar seu conjunto de trabalho real e escolher entre 10 chaves para expirar, para que nunca vejamos nada ser expulso do que estamos usando.

1. 
   É o nosso servidor pubsub. Quando um usuário faz algo em um quadro ou cartão, queremos enviar uma mensagem com esse delta para todos os clientes conectados ao websocket que estão inscritos no objeto que mudou, para que todos os nossos processos Node sejam inscritos em um canal pubsub que se propaga essas mensagens, e eles propagam isso para os websockets devidamente autorizados e inscritos.
   
2. 
   Nós meio que o usamos para apoiar o socket.io, mas como usamos apenas os websockets, e como o socket.io é muito chato para escalar como precisamos no momento, temos um patch que desativa todos, exceto um canal que é necessário para nós.
   
3. 
   Para nossos usuários que não possuem websockets, temos que manter uma lista das ações que aconteceram em cada canal de objeto desde a última solicitação de pesquisa do usuário. Para isso, usamos uma lista que limita os 100 elementos mais recentes e um contador auxiliar de quantos elementos foram adicionados à lista desde que ela foi criada. Então, quando estamos respondendo a uma solicitação de pesquisa de um navegador desse tipo, podemos verificar o último elemento que ele relata que viu e enviar apenas as mensagens que foram adicionadas à fila desde então. Portanto, isso reduz uma solicitação de pesquisa a apenas uma verificação de permissões e uma única verificação de chave Redis na maioria dos casos, o que é muito rápido.
   
4. 
   Armazenamos alguns dados efêmeros sobre o status ativo de usuários conectados no Redis, porque esses dados mudam com frequência e não é necessário mantê-los no disco.
   
5. 
   Armazenamos chaves de curta duração para dar suporte a logins OAuth no Redis.
   

Adoramos o Redis; depois de ter uma instância dele em execução, você deseja usá-lo para todos os tipos de coisas. O único problema real que tivemos com ele é com clientes de consumo lento consumindo o espaço disponível.

Usamos o MongoDB para nossas necessidades de banco de dados mais tradicionais.