CQRS e Consistência Eventual: Como Projetar Telas e APIs para Lidar com Atrasos na Leitura

O Desafio Invisível dos Sistemas Modernos

Quando construímos aplicações, assumimos instintivamente que o banco de dados responde instantaneamente. Salvamos um cadastro e esperamos vê-lo na listagem logo no clique seguinte. No entanto, em sistemas distribuídos de grande escala, essa ilusão de sincronicidade desaba diante da necessidade de desempenho e resiliência. É nesse cenário que o CQRS entra em cena, separando o modelo de escrita do modelo de leitura.

Na prática, CQRS significa ter um caminho dedicado para registrar o que acontece e outro totalmente otimizado para exibir esses dados. O problema é que ler de uma base separada gera um atraso inevitável conhecido como consistência eventual. Os dados chegam ao destino, mas levam frações de segundo ou até segundos para aparecer, desafiando a forma como projetamos interfaces de usuário e APIs.

Para um usuário comum, olhar para uma tela vazia após clicar em um botão de confirmação gera desconfiança imediata. Ele pensa que o sistema travou e clica novamente, criando duplicatas indesejadas no backend. Projetar telas e APIs para lidar com essa assincronia exige escolhas arquiteturais cuidadosas que combinam engenharia de software e design de experiência do usuário.

Entendendo a Arquitetura CQRS na Prática

O acrônimo CQRS vem de Command Query Responsibility Segregation, ou Seguração de Responsabilidade entre Comandos e Consultas. Em termos simples, um comando altera o estado do sistema, como criar um pedido ou mudar uma senha. Uma consulta apenas busca informações, como exibir o extrato bancário ou listar produtos disponíveis em uma loja virtual.

Em arquiteturas tradicionais, usamos a mesma estrutura de dados para as duas tarefas. Conforme o sistema cresce, as consultas complexas travam as gravações e vice-versa. O CQRS resolve isso separando os mundos. O banco de escrita foca na integridade rigorosa, enquanto o banco de leitura é desenhado apenas para entregar consultas rápidas, frequentemente usando tecnologias diferentes.

O grande ganho dessa divisão é a escalabilidade independente de cada lado. Podemos ter dez servidores lendo um catálogo de produtos replicado e apenas um servidor dedicado a processar as compras. Essa flexibilidade é indispensável para plataformas de e-commerce e redes sociais com picos massivos de acesso simultâneo.

O Impacto da Consistencia Eventual na Interface

A consistência eventual é a garantia de que, se nenhum novo dado for enviado, todas as cópias de leitura eventualmente refletirão a alteração feita. O ponto crítico é o 'eventualmente'. Esse intervalo, por menor que seja, expõe o sistema a situações desconfortáveis onde o usuário fez uma alteração, mas a tela mostra o estado anterior.

Imagine um painel financeiro onde você transfere dinheiro. Se o saldo atualizado demora meio segundo para aparecer na tela de extrato, você pode achar que a transação falhou. Na prática, a API aceitou o comando com sucesso, mas o mecanismo que atualiza a tabela de leitura ainda está processando a fila de eventos em segundo plano.

Para contornar isso, as interfaces precisam assumir uma postura conversacional e transparente. Em vez de congelar a tela esperando uma resposta síncrona impossível, a aplicação deve informar visualmente que a operação está em andamento, transformando uma limitação técnica em um elemento de feedback claro para quem interage com o sistema.

Estratégias de Design de API para Comunicação Assíncrona

Quando adotamos comandos assíncronos, as APIs não podem mais retornar o objeto completo recém-criado como faziam no modelo REST tradicional. O servidor recebe a intenção de gravação, valida os dados básicos e responde imediatamente com um código HTTP aceito, indicando que o trabalho foi delegado para uma fila de processamento.

A resposta típica de uma API orientada a CQRS costuma retornar um identificador único do recurso e um link de status ou localização. Isso permite que o cliente saiba exatamente onde consultar o andamento daquela tarefa específica sem sobrecarregar o servidor principal com requisições repetitivas e desnecessárias.

Abaixo temos um exemplo conceitual em Node.js mostrando uma rota de comando que despacha uma mensagem para um barramento de eventos e retorna o status de aceitação de forma imediata:

app.post('/api/v1/pedidos', async (req, res) => {
  const comandoId = gerarUUID();
  const dadosPedido = req.body;

  // Publica o comando em um barramento de mensagens (ex: RabbitMQ, Kafka)
  await barramentoEventos.publicar('pedido.criado', {
    comandoId,
    ...dadosPedido,
    timestamp: new Date().toISOString()
  });

  // Retorna imediatamente com o status 202 (Accepted)
  return res.status(202).json({
    status: 'processando',
    identificador: comandoId,
    mensagem: 'Seu pedido foi recebido e está sendo processado.'
  });
);

Esse padrão desacopla o tempo de resposta da API do tempo real de execução do banco de dados de leitura, garantindo alta disponibilidade mesmo sob quedas parciais de infraestrutura em microsserviços.

Técnicas de UX para Mascarar o Atraso de Leitura

O design de interface desempenha um papel salvador na engenharia de software distribuída. Quando sabemos que haverá um atraso na propagação da leitura, podemos usar técnicas visuais para enganar a percepção de tempo do usuário, mantendo a sensação de fluidez e interatividade imediata.

Uma das abordagens mais eficazes é a atualização otimista de estado. Quando o usuário clica para editar seu perfil e muda o apelido, a interface atualiza o texto na tela instantaneamente antes mesmo da API confirmar o recebimento. Se a requisição falhar no servidor, a tela desfaz a alteração e exibe um aviso amigável.

Outra técnica indispensável é o uso de estados intermediários de carregamento com esqueletos visuais e indicadores de progresso textuais, como 'Sua alteração está sendo aplicada'. Isso educa o usuário sobre o comportamento assíncrono do sistema, reduzindo drasticamente a ansiedade e os cliques duplicados em botões de ação.

Considerações Finais sobre Resiliência e Arquitetura

Projetar sistemas baseados em CQRS e consistência eventual exige uma mudança profunda na mentalidade de desenvolvimento. Abandonamos a busca cega por transações síncronas perfeitas e abraçamos a realidade dos sistemas distribuídos, onde a comunicação é baseada em mensagens e o tempo é elástico.

O sucesso de uma arquitetura como essa depende de uma comunicação alinhada entre engenheiros de backend e designers de produto. Quando a API e a interface trabalham juntas para guiar o usuário através dos atrasos inevitáveis da propagação de dados, construímos aplicações robustas, altamente escaláveis e genuinamente agradáveis de usar.