Projete um sistema de chat

Requisitos. Chats individuais e em grupos pequenos, entrega em tempo real, histórico de mensagens em vários dispositivos, presença online e entrega para usuários que estão offline. Não funcionais: baixa latência, mensagens nunca podem se perder depois de confirmadas, e a ordem precisa ser consistente dentro de uma conversa.

• Transporte: os clientes mantêm um WebSocket persistente, para o servidor poder enviar mensagens na hora. Long polling é uma alternativa de reserva.
• Gateways com estado: os servidores de WebSocket mantêm conexões abertas, então têm estado. Um registro de sessões (por exemplo, no Redis) mapeia cada usuário online para o gateway que segura a conexão dele. Mantenha a lógica de negócio em serviços separados, sem estado.
• Roteamento: o serviço de chat persiste a mensagem, descobre o gateway de cada destinatário e publica nele (via pub/sub). Destinatários offline recebem uma notificação push.
• Armazenamento: as mensagens são particionadas por conversation_id e ordenadas por um número de sequência por conversa - um encaixe natural para um banco de colunas largas.

Um exemplo: um cliente com as mensagens 1, 2, 4 e 5 percebe que falta a 3 e pede essa mensagem ao servidor.

Os números de sequência permitem que os clientes detectem buracos e sincronizem ao reconectar, pedindo “as mensagens depois da sequência N”. Quem atribui os números é o servidor, porque os relógios dos clientes não concordam. O servidor armazena a mensagem antes de confirmá-la ao remetente, então uma mensagem confirmada sobrevive a uma queda. A presença usa heartbeats: um usuário que perde vários heartbeats é marcado como offline. Em chats de grupo, o serviço faz o fan-out de cada mensagem para o gateway de cada membro.