Projetar um Sistema de Quadro Branco Colaborativo em Tempo Real

# Arquitetura de Alto Nível Componentes e fluxo de requisição/dados: ``` ┌──────────────┐ Clientes Web/Móveis/Desktop │ Clientes │ (Renderização de tela, réplica CRDT local, Clientes ─────► │ (100/quadro) │ cliente WebSocket, buffer offline) └──────┬───────┘ │ HTTPS (REST) + WSS (WebSocket) ┌──────▼───────┐ │ CDN │ (ativos estáticos, imagens exportadas) └──────┬───────┘ ┌──────▼───────────────┐ │ Balanceador de Carga Global │ (L7, terminação TLS, │ + Gateway de API │ autenticação, limitação de taxa) └───┬───────────────┬───┘ Tráfego REST │ │ Upgrade WS (fixo por sessionId) ┌──────────────▼──┐ ┌─────▼───────────────┐ │ Serviços de App │ │ Servidores de Colab │ │ Sem Estado │ │ em Tempo Real (WS) │ │ (autenticação, │ │ - mantêm estado do │ │ CRUD de quadros,│ │ quadro em memória│ │ compartilhamento,│ │ - mesclam operações (CRDT)│ │ exportações) │ │ - transmitem deltas│ └───┬────────┬─────┘ │ - transmitem deltas│ │ │ └───┬───────────┬──────┘ ┌───────▼──┐ ┌───▼─────┐ ┌────▼────┐ ┌───▼────────┐ │ DB de │ │ Armazém │ │ Redis │ │ Roteamento│ │ Metadados│ │ de Objetos│ │ Pub/Sub │ │ de Sessão │ │(Postgres)│ │ (S3) │ │+Presença│ │(Hashing │ └──────────┘ └─────────┘ └─────────┘ │ Consistente)│ │ └────────────┘ ┌───────▼─────────────┐ ┌─────────────────────────────┐ │ Armazém de Documentos│ │ Trabalhadores Assíncronos │ │ / Operações │◄──│ (fila Kafka) │ │ (DynamoDB/Cassandra: │ │ - criação de snapshots │ │ log de ops + snapshots)│ │ - geração de miniaturas/exportações│ └─────────────────────┘ │ - análises │ └─────────────────────────────┘ ``` **Resumo da interação:** Clientes autenticam via API Gateway (REST), depois abrem um WebSocket persistente para um servidor de Colaboração em Tempo Real. O gateway usa hashing consistente em `sessionId` para que todos os participantes de um quadro caiam no mesmo servidor (ou um pequeno conjunto de réplicas), mantendo o estado vivo autoritativo em um só lugar. Serviços de Aplicativo lidam com CRUD não em tempo real (criação de quadros, compartilhamento, listagem, exportações). ## 2. Comunicação em Tempo Real - **Protocolo:** WebSocket (WSS) para mensagens bidirecionais full-duplex e de baixa latência. Retrocede para HTTP long-polling via uma biblioteca como Socket.IO para redes restritivas. Canais de dados WebRTC são considerados para cursores/presença peer-to-peer, mas um modelo com retransmissão pelo servidor é escolhido pela simplicidade e confiabilidade. - **Modelo de mensagem:** Clientes enviam **operações/deltas** pequenas (por exemplo, `{type:'stroke_add', objId, points, color}`, `{type:'obj_move', objId, dx, dy}`) em vez do estado completo do quadro. O servidor valida, atribui uma sequência/versão, mescla e transmite o delta para todos os outros membros da sessão. - **Fan-out:** Cada servidor em Tempo Real mantém o conjunto de conexões por quadro em memória e transmite deltas diretamente. Para quadros cujos membros se espalham por vários servidores, o servidor de origem publica a operação em um canal Redis Pub/Sub com chave `sessionId`; servidores inscritos retransmitem para suas conexões locais. - **Presença e cursores:** Dados de alta frequência e baixo valor (posições de cursor ao vivo, seleções) são limitados (~30–60ms) e enviados com melhor esforço, nunca persistidos. - **Meta de latência (<200ms):** Alcançada via clusters de Tempo Real regionais, roteamento fixo (sem saltos entre regiões), cargas úteis binárias/JSON compactas minúsculas e renderização local otimista (o cliente aplica sua própria operação imediatamente e depois reconcilia). ## 3. Modelo de Dados **Metadados do quadro (Postgres — relacional, transacional):** - `boards(board_id, owner_id, title, created_at, updated_at, latest_snapshot_id)` - `users(user_id, name, email, ...)` - `board_permissions(board_id, user_id, role[owner|editor|viewer])` - `sessions(session_id, board_id, started_at, active_user_count)` **Conteúdo do quadro (DynamoDB/Cassandra — alta taxa de transferência de gravação, amigável para anexos):** - **Log de operações:** chave de partição `board_id`, chave de ordenação `version` (monotônica). Cada linha é uma operação `{op_type, object_id, payload, user_id, timestamp}`. - **Snapshots:** blobs de estado completo materializados periodicamente `{board_id, snapshot_version, state_json/binary}` armazenados em armazenamento de objetos (S3) com uma linha de ponteiro. Carregar um quadro = snapshot mais recente + reprodução das operações desde essa versão do snapshot. **Estrutura do objeto dentro de um quadro:** ``` WhiteboardObject { id, type: "stroke" | "text" | "sticky", layer/zIndex, geometry: { x, y, width, height, rotation }, props: { // específico do tipo stroke: { points:[...], color, thickness }, text: { content, font, color }, sticky: { content, bgColor } }, createdBy, lastModified, version } ``` **Resolução de conflitos:** Use um **CRDT** (por exemplo, um CRDT de lista/mapa como os encontrados em Yjs/Automerge) ou OT para o conjunto de objetos, para que edições concorrentes (dois usuários movendo/editando objetos diferentes ou iguais) converjam deterministicamente sem um bloqueio central. Cada objeto carrega um relógio lógico para o último escritor vence em atualizações de propriedades conflitantes. **Grandes ativos/binários** (imagens carregadas, PNG/PDF exportados) residem em armazenamento de blobs estilo S3, referenciados por URL no objeto. ## 4. Estratégia de Escalabilidade e Confiabilidade **Escalando para 10k sessões / 1M usuários:** - **Camada de aplicativo sem estado:** Horizontalmente escalada automaticamente atrás do balanceador de carga; trivial adicionar nós. - **Camada em Tempo Real:** Fragmentada por `sessionId` via hashing consistente. Com no máximo 100 usuários por quadro, 10k sessões = até ~1M conexões WS concorrentes. Um único nó ajustado lida com ~10–50k conexões; o fan-out é dimensionado para que os membros de cada quadro se concentrem em um nó. Autoscale por contagem de conexões e CPU. - **Redis:** Clusterizado, usado para fan-out Pub/Sub e presença; particionado por sessão. - **Bancos de dados:** Postgres com réplicas de leitura para metadados; DynamoDB/Cassandra escalam horizontalmente para o log de operações de alto volume. O armazenamento de objetos escala efetivamente infinitamente. - **Snapshotting:** Trabalhadores assíncronos compactam o log de operações em snapshots em uma cadência (por exemplo, a cada N operações ou T segundos) para limitar o custo de reprodução e o armazenamento. **Alta disponibilidade (99,9%):** - Implantação Multi-AZ para cada camada; multi-região para recuperação de desastres. - Servidores em Tempo Real executados com um standby/réplica quente por quadro; em caso de falha do nó, os clientes reconectam automaticamente e o novo nó reidrata o estado do snapshot mais recente + log de operações (os últimos segundos de operações em memória podem ser reenviados pelos clientes de seu buffer local). - Verificações de integridade + failover automatizado no balanceador de carga. - Backpressure e limitação de taxa para proteger contra tempestades de operações. - O log de operações durável fornece um ponto de recuperação — nenhum trabalho confirmado é perdido mesmo em caso de falha do servidor. ## 5. Trade-offs **Trade-off escolhido: Latência/disponibilidade sobre consistência forte (AP sobre CP), usando CRDTs.** Priorizo responsividade sub-200ms e tolerância offline, permitindo que os clientes apliquem edições otimisticamente e resolvam conflitos com CRDTs/último escritor vence, aceitando **consistência eventual**. O benefício: a interface do usuário parece instantânea, os usuários podem editar durante breves partições de rede e o sistema permanece disponível durante failovers. O custo: em casos raros de edições concorrentes, o resultado convergido pode não corresponder à expectativa intuitiva de nenhum usuário (por exemplo, edições simultâneas no mesmo texto), e os metadados CRDT adicionam sobrecarga de memória/armazenamento. Para um quadro branco, essa é a decisão correta — a colaboração criativa valoriza a fluidez e a disponibilidade muito mais do que a consistência serializada estrita que uma abordagem transacional/de bloqueio (CP) imporia, o que adicionaria latência de ida e volta e reduziria a disponibilidade durante partições. **Trade-off secundário:** manter o estado vivo autoritativo em memória em um único nó em Tempo Real por quadro (transmissões rápidas, mesclagem simples) versus uma camada totalmente sem estado (mais resiliente, mas maior latência). Mitigado com snapshots + log de operações para que qualquer nó possa reconstruir o estado em caso de failover.

1. Arquitetura de Alto Nível Um bom design é um híbrido de APIs sem estado, workers de colaboração em tempo real com estado, armazenamento durável e um fluxo de eventos. Componentes principais: - Clientes Web/mobile - CDN para ativos estáticos - Gateway de API / Balanceador de Carga - Serviço de autenticação - Serviço de metadados do quadro branco - Serviço de colaboração em tempo real - Roteador de sessão / serviço de presença - Barramento de mensagens / fluxo de eventos - Pipeline de persistência - Banco de dados primário para metadados - Armazenamento de objetos/documentos para instantâneos do quadro branco e estado do elemento - Cache (Redis) - Monitoramento, rastreamento, limitação de taxa Diagrama de texto: Cliente -> CDN para ativos do aplicativo -> Gateway de API / LB -> Serviço de Autenticação -> Serviço de API do Quadro Branco -> Roteador de Sessão -> Nós de Colaboração em Tempo Real (WebSocket) -> Estado da sessão Redis / em memória -> Tópico Pub/Sub ou Kafka por fragmento -> Workers de persistência -> Armazenamento de Instantâneos -> DB de Metadados Fluxo: - O usuário abre o aplicativo e se autentica. - O cliente busca metadados do quadro branco e o estado persistido mais recente por meio de APIs REST/HTTP. - O cliente então atualiza para WebSocket para a sessão do quadro. - O roteador de sessão envia o cliente para o nó de colaboração responsável por aquele quadro branco. - Os usuários enviam operações como segmento de traço de desenho, criação de caixa de texto, movimentação de objeto, edição de nota adesiva. - O nó de colaboração valida, sequencia e transmite operações para todos os participantes da sessão. - As operações são anexadas a um log de eventos e periodicamente compactadas em instantâneos. - Ao reconectar ou reabrir, o cliente carrega o instantâneo mais recente mais as operações recentes. Particionamento prático: - Use hashing consistente ou um serviço de mapeamento quadro-para-nó para que uma sessão de quadro seja de propriedade de um nó de colaboração por vez. - Isso simplifica a ordenação e o tratamento de conflitos. - Com 10.000 sessões simultâneas e até 100 usuários/sessão, o sistema é grande, mas gerenciável com escalonamento horizontal de nós de colaboração. 2. Comunicação em Tempo Real Protocolo: - WebSocket sobre TLS é a escolha principal. - Razão: comunicação bidirecional de baixa latência, amplo suporte a navegadores/dispositivos móveis, mais simples que long polling e eficiente para atualizações pequenas e frequentes. Modelo de atualização: - O cliente envia operações, não o estado completo do quadro. - Exemplos de operações: - start_stroke, append_stroke_points, end_stroke - create_text, edit_text - create_sticky, move_object, resize_object, delete_object - O nó de colaboração marca o tempo/sequencia as operações e as transmite para todos os clientes naquela placa. Ordenação e fanout: - Dentro de um único quadro, mantenha um número de sequência monotonicamente crescente. - Todas as operações desse quadro passam por seu nó de colaboração proprietário, que fornece ordem total por quadro. - Transmite localmente para clientes conectados; se réplicas ou vários nós servirem ao mesmo quadro para failover, use Redis Pub/Sub ou Kafka para replicação/eventos. Meta de latência abaixo de 200ms: - Mantenha os nós de colaboração geograficamente próximos aos usuários usando implantações regionais. - Use roteamento fixo para que todos os usuários de um quadro acessem o mesmo nó na região, quando possível. - Transmita apenas deltas, comprima cargas úteis, agrupe pontos de caneta a cada poucos milissegundos. - Para desenho à mão livre, permita a renderização otimista local imediatamente no remetente antes do ack do servidor, e depois reconcilie, se necessário. Tratamento de conflitos: - Para edições baseadas em objetos, como mover caixa de texto ou editar nota adesiva, use versionamento por objeto. - Para estado altamente concorrente, use transformações operacionais ou mesclagem inspirada em CRDT se for necessária edição rica multiusuário. - Para um sistema de quadro branco de alto nível, um modelo mais simples é aceitável: - Traços de caneta são somente anexáveis e naturalmente se mesclam bem. - Transformações de objetos usam last-write-wins ou ordenação do servidor. - O conteúdo de texto pode usar bloqueio de edição de objeto inteiro mais simples inicialmente, ou evoluir mais tarde para OT/CRDT para edição de texto concorrente. 3. Modelo de Dados Use um modelo dividido: DB relacional de metadados + conteúdo do quadro em armazenamento de documentos/blob + log de operações. A. Metadados do quadro branco Tabela: Whiteboard - board_id - owner_user_id - title - created_at - updated_at - last_snapshot_id - access_policy - region - status Tabela: WhiteboardMember - board_id - user_id - role (owner/editor/viewer) - invited_at Tabela: ActiveSession - session_id - board_id - user_id - connection_id - joined_at - last_heartbeat - presence_state B. Modelo de conteúdo do quadro Represente o quadro como uma coleção de elementos em uma tela infinita ou limitada. Campos base do elemento: - element_id - board_id - type: stroke | text | sticky_note | shape - created_by - created_at - updated_at - z_index - position {x, y} - rotation - style object - version - deleted flag Elemento de traço: - element_id - points: lista de pontos comprimida por polilinha ou Bezier - color - width - opacity Elemento de texto: - element_id - text_content - font_family - font_size - bounding_box Elemento de nota adesiva: - element_id - text_content - background_color - bounding_box C. Log de operações Tabela ou stream: BoardOperation - op_id - board_id - seq_no - user_id - op_type - target_element_id - payload - client_timestamp - server_timestamp Exemplos de payload: - criar elemento com propriedades iniciais - anexar pontos de traço - mover objeto de posição antiga para nova posição - corrigir texto - excluir elemento D. Instantâneos Objeto de instantâneo armazenado no armazenamento de documentos/blob: - snapshot_id - board_id - base_seq_no - created_at - estado do quadro serializado ou partições espaciais fragmentadas Por que instantâneos + log de operações: - Reproduzir todo o histórico para sempre se torna muito lento. - Instantâneos permitem carregamento rápido. - Operações recentes após o instantâneo restauram o estado mais recente. Otimização opcional para quadros grandes: - Fragmentação espacial: particione a tela em blocos/regiões para que os clientes carreguem apenas o conteúdo visível. - Útil se os quadros ficarem muito grandes. 4. Estratégia de Escalabilidade e Confiabilidade Escalabilidade A. Escalonamento horizontal de nós de colaboração - O serviço de colaboração é o caminho crítico. - Cada nó mantém sessões de quadro ativas em memória atribuídas a ele. - As sessões são fragmentadas por board_id. - Se o tamanho médio da sessão for modesto, muitas sessões podem ser hospedadas por nó. - O balanceador de carga + roteador de sessão garantem que os usuários entrem no nó correto. B. Persistência orientada a eventos - Não escreva síncronamente cada ponto de caneta no banco de dados primário antes da transmissão; isso prejudicaria a latência. - Em vez disso: - o nó de colaboração aceita a operação - anexa ao log durável / fila replicada - transmite imediatamente - workers assíncronos persistem e compactam em instantâneos - Para durabilidade, use Kafka/Pulsar ou um log de gravação antecipada replicado antes do ack se garantias mais fortes forem necessárias. C. Tráfego de desenho eficiente - A ferramenta de caneta pode gerar muitos pontos por segundo. - Reduza o volume por: - simplificação de pontos no lado do cliente - agrupamento de pontos a cada 10-30ms - codificação binária em vez de JSON verboso, se necessário - gzip/permessage-deflate no WebSocket D. Cache - Cache Redis para metadados do quadro, presença, mapa de roteamento, instantâneos quentes. - Quadros e permissões recentes podem ser armazenados em cache para reduzir a carga do banco de dados. E. Estratégia de armazenamento - Banco de dados relacional (PostgreSQL/MySQL) para usuários, quadros, permissões, metadados de compartilhamento. - Armazenamento de documentos/blob (S3/armazenamento de objetos ou banco de dados de documentos) para instantâneos. - Sistema de stream/log para operações. - Isso evita forçar um banco de dados a lidar com todos os padrões de acesso. Confiabilidade / Alta Disponibilidade A. Implantação Multi-AZ - Execute API, nós de colaboração, Redis e bancos de dados em várias zonas de disponibilidade. - Balanceadores de carga verificam a integridade das instâncias e redirecionam automaticamente. - 99,9% de tempo de atividade é alcançável com multi-AZ e implantações contínuas. B. Failover do nó de colaboração - Como a propriedade do quadro tem estado, a falha do nó é importante. - Mitigação: - as operações são continuamente replicadas para o log durável - checkpoints em memória periódicos ou instantâneos rápidos - o roteador de sessão detecta a perda do nó e reatribui o quadro a outro nó - os clientes reconectam automaticamente e recarregam o instantâneo + operações de cauda - Curta interrupção é aceitável; os usuários se recuperam rapidamente. C. Presença e heartbeats - Heartbeats do WebSocket detectam desconexões. - O serviço de presença atualiza o estado do usuário ativo com TTLs no Redis. D. Backpressure e proteção - Limitação de taxa por usuário e por quadro. - Descarte ou coalesça eventos de movimento/arrasto excessivos. - Separe o tráfego do plano de controle do plano de dados. - Proteja contra uma sessão barulhenta consumindo todos os recursos do nó. E. Escolhas de durabilidade Duas opções: - Menor latência: ack após a operação ser aceita em memória e replicada assíncronamente. - Maior durabilidade: ack apenas após anexar ao log replicado. Eu escolheria ack-após-anexar-ao-log para mutações de objetos e tratamento em lote para segmentos de caneta para equilibrar confiabilidade e velocidade. Razão da capacidade - 10.000 sessões simultâneas x média talvez 10 usuários ativos/sessão é 100.000 conexões simultâneas em média; pior caso 1.000.000 se todas as sessões tiverem 100 usuários, mas esse provavelmente não é o estado estável pretendido. O design deve suportar centenas de milhares de WebSockets horizontalmente. - Os nós de colaboração podem suportar dezenas de milhares de conexões ociosas/leves cada ou menos para sessões pesadas, portanto, escalam com autoescalonamento e fragmentam por contagem de quadros ativos e taxa de eventos. 5. Trade-off Principal trade-off: consistência vs. latência. Eu priorizaria baixa latência e colaboração suave em vez de consistência global estrita para cada ação. O que isso significa: - Os clientes renderizam otimistamente seu próprio desenho imediatamente. - O servidor fornece ordenação autoritativa por quadro, mas algumas operações podem ser mescladas usando regras simples como ordem do servidor ou last-write-wins. - A persistência é quase em tempo real, em vez de bloquear cada atualização em uma transação de banco de dados. Por que esse trade-off é bom aqui: - A experiência do usuário do quadro branco é altamente interativa; os usuários notam o atraso muito mais do que reconciliações ocasionais e menores. - Traços de caneta e movimentos de objetos são tolerantes à consistência eventual dentro de uma janela muito pequena. - Transações serializáveis estritas para todas as edições aumentariam a latência e reduziriam a taxa de transferência. Custo dessa escolha: - Durante edições concorrentes no mesmo objeto, os usuários podem ver pequenos saltos ou atualizações sobrescritas. - Recuperar-se de uma falha de nó pode reproduzir uma pequena cauda de operações. - A edição de texto concorrente rica pode precisar de um mecanismo OT/CRDT mais avançado mais tarde. Resumo do design - APIs REST para autenticação, metadados do quadro, instantâneos. - WebSockets para colaboração ao vivo. - Um nó de colaboração proprietário lógico por quadro para sequenciamento e fanout. - Redis/cache para roteamento e presença. - Kafka/PubSub/log de eventos para streaming de operações duráveis. - DB relacional para metadados/permissões, armazenamento de objetos ou armazenamento de documentos para instantâneos e estado do quadro. - Implantação Multi-AZ, autoescalonamento, reconexão/failover e instantâneo assíncrono para confiabilidade e escala. Essa arquitetura atende ao requisito de quase tempo real, suporta persistência, escala para muitas sessões ativas e mantém o sistema operacionalmente prático.