Chat em tempo real

01 · CONTEXTO

O que um chat em tempo real precisa resolver

Um chat entrega mensagens entre pessoas em segundos, mantém quem está online, guarda o histórico e avisa quem está fora. Os três pontos difíceis são manter conexões abertas em grande número, levar a mensagem ao servidor certo e não perder nada quando o destinatário está offline. Os roteiros de entrevista de referência partem de uma escala de dezenas de milhões de usuários ativos por dia, e produtos como Facebook Messenger e WhatsApp são citados na casa de dezenas de bilhões de mensagens diárias.

Neste estudo, a comunicação usa WebSocket, o roteamento depende de balanceamento de carga e o histórico exige escolher e particionar um banco. Presença e geração de IDs aparecem no texto, sem página própria na trilha.

02 · CONEXÃO

Por que o chat não é uma API HTTP comum

O HTTP é iniciado pelo cliente, então o servidor não tem como empurrar uma mensagem nova por conta própria. Consultar o servidor de tempos em tempos (polling) pode sair caro, dependendo da frequência. O WebSocket resolve isso com uma conexão bidirecional e persistente, aberta uma vez e usada nos dois sentidos.

A consequência de manter conexões abertas é que o servidor de chat deixa de ser um serviço sem estado: ele precisa saber quem está ligado a ele. Nas arquiteturas de referência, os serviços de login, perfil e similares continuam sem estado, e o serviço de chat é o único com estado.

03 · ENTREGA

Levando a mensagem ao servidor certo

Com muitos servidores de chat, o remetente e o destinatário quase nunca estão no mesmo. Um desenho simples começa com um único servidor e logo esbarra no roteamento: é preciso levar cada mensagem ao servidor onde o destinatário está conectado. Uma saída é um canal de pub/sub entre os servidores.

1. O remetente mantém uma conexão persistente; o balanceador a encaixa em um servidor de chat, que passa a ser o ponto de entrada das mensagens dele.

2. Antes de tentar entregar, o servidor grava a mensagem no histórico e na caixa de entrada. Se a entrega falhar depois, nada se perde.

3. Só então publica a mensagem no canal de pub/sub. Esse canal não garante entrega, o que é aceitável porque a gravação já aconteceu.

4. O servidor onde o destinatário está conectado recebe a publicação. Sem esse passo, remetente e destinatário em servidores diferentes nunca se encontrariam.

5. O servidor B empurra a mensagem pela conexão aberta, sem o cliente precisar perguntar.

O ponto sutil está na ordem das operações: a mensagem é gravada na caixa de entrada e no histórico antes de ser publicada. O pub/sub descrito na referência entrega no máximo uma vez e não garante entrega, o que só é aceitável porque a gravação já foi feita.

04 · PRESENÇA E OFFLINE

Quem está online e o que fazer quando ninguém atende

A presença é mantida por sinais de vida: enquanto o cliente está conectado, ele ou o servidor emitem heartbeats periódicos. Os intervalos variam por desenho; uma referência cita um sinal do cliente a cada poucos segundos, outra, pings do servidor a cada dezenas de segundos. Se os sinais param além da tolerância, o usuário passa a constar como offline, o que evita que uma queda breve de rede troque o status o tempo todo.

1. Enquanto o destinatário está conectado, sinais periódicos de vida (heartbeat) mantêm a presença dele como online.

2. A conexão do destinatário cai e os heartbeats param. Passado o tempo de tolerância, a presença o marca como offline.

3. Ao ver que o destinatário não está online, o servidor mantém a mensagem na caixa de entrada até ele voltar.

4. Em paralelo, uma fila alimenta o worker que dispara a notificação push, para o usuário saber que há mensagem esperando.

5. Quando o dispositivo reconecta, ele sincroniza o que ficou retido, em ordem de ID.

Para destinatários offline, as referências convergem em duas peças: reter a mensagem no servidor até o usuário voltar e disparar uma notificação push. Uma delas considera o push a integração de terceiros mais importante para um app de chat.

05 · ORDEM E ESCALA

Ordenar, armazenar e crescer

Na ordenação, o carimbo de tempo de criação não basta, porque duas mensagens podem ser criadas ao mesmo tempo. A referência pede um identificador único e ordenável por tempo, de modo que linhas novas tenham IDs maiores que as antigas. Outra referência trata o assunto de forma mais pragmática: usuários preferem ver mensagens novas o quanto antes a ter ordem garantida, então a ordem global não é perseguida diretamente.

Para o histórico, uma das referências recomenda um armazenamento chave-valor pela facilidade de escalar horizontalmente e pela baixa latência de acesso, e a outra escolhe DynamoDB pelo mesmo tipo de desempenho e escalabilidade.

1. Cada servidor segura muitas conexões abertas, então a frota cresce em número de máquinas conforme cresce a base de usuários conectados.

2. Um servidor de chat cai e leva consigo as conexões que segurava. O diagrama destaca o servidor que caiu e o balanceador, que fica impactado.

3. O histórico é o único estado durável do conjunto, por isso é ele que se particiona para acompanhar a escrita de todas as conversas.

Na frota de conexões, uma referência estima que cada conexão ocupa poucos kilobytes de memória, de modo que cerca de dez gigabytes numa única máquina bastariam para segurar todas as conexões do cenário de referência. A outra lembra que o WhatsApp servia de um a dois milhões de usuários por host, e que ainda assim isso exige centenas de servidores de chat. O volume agregado, em um cenário de duzentos milhões de usuários conectados ao mesmo tempo, chega à ordem de dezenas de milhares de mensagens por segundo.