Módulo 1 · 6 de 7

Caso real: o cache que salvou o projeto

Leitura: ~3 min

Caso real

Vou compartilhar com você um caso que vivi quando era designer sênior, antes de me tornar gerente. Nós começamos um projeto para um cliente grande de manufatura, uma empresa que fabricava produtos há mais de 30 anos. O banco de dados deles era enorme: todos os produtos, cada peça que compunha cada produto, históricos de produção. Um banco de dados robusto, cheio de consultas, com vários sistemas conectados.

A missão: desenhar um sistema novo que precisava consultar tudo que estava nesse banco. E aí veio o problema. Como fazer essa consulta?

Se toda vez que o usuário fizesse uma busca o sistema puxasse direto do banco de dados, cada busca seria extremamente lenta. Estamos falando de minutos, não segundos. Além disso, com muitos usuários buscando ao mesmo tempo, o volume de requisições poderia derrubar o servidor. Imagina a experiência: o usuário clica em "Buscar" e... nada. O banco lento. O servidor caindo. Frustração total.

Então eu participei da discussão com o time técnico. A pergunta era: qual experiência a gente quer entregar? No final, a equipe optou por usar cache, salvar localmente as informações mais buscadas pelos usuários, para que essas consultas fossem muito mais rápidas.

Sem cache App Banco de dados (consulta direta) lento -- minutos de espera Com cache App Cache local instantâneo sincroniza Banco de dados rápido segundos
Antes e depois do cache: sem cache, cada consulta vai direto ao banco e demora minutos. Com cache local, a resposta é quase instantânea, e a sincronização acontece em segundo plano.

Mas não era a solução óbvia. O cache trazia desafios sérios. Primeiro, segurança: por ser um sistema interno, se alguém acessasse o computador de outro funcionário, poderia ver dados que não deveria. Segundo, sincronização: se a informação muda no servidor, o sistema precisa avisar que a versão local está desatualizada. Terceiro, o esforço de desenvolvimento era consideravelmente maior.

O ponto é: eu, como designer, estava nessa mesa. Não para programar, mas para pensar no que pesava na experiência do usuário. E isso fez diferença. Participar dessa discussão me permitiu antecipar cenários, propor soluções de interface para os problemas de sincronização e garantir que o usuário sempre soubesse o estado da informação que estava vendo.

Nem sempre a solução técnica óbvia é a melhor para o usuário. E é exatamente por isso que você precisa estar nessa conversa.