Latência e decisões de produto
TLDR
Quando uma tela “demora”, às vezes o motivo é a arquitetura: a jornada chama vários sistemas em sequência (um depois do outro), e cada chamada soma tempo. Isso vira decisão de produto: o que mostrar na hora, o que carregar depois, o que fazer em segundo plano. Quem define o que é “aceitável” e o que pode aparecer depois é produto e negócio, com o suporte da engenharia.
Por que isso importa
Entender por que uma tela demora sem culpar só “o time” — pode ser quantidade de sistemas na sequência. Decidir com produto o que precisa aparecer na hora e o que pode carregar em seguida melhora a experiência e a expectativa.
Conceito (em linguagem simples)
- Chamadas em sequência: Cada sistema que a tela chama “um depois do outro” soma tempo (rede + processamento). Cinco sistemas, cada um com 200 ms, já são 1 segundo só de ida e volta.
- Decisão de produto: O que o usuário “precisa ver na hora”? Às vezes é só uma coisa (ex.: “pedido recebido”); o restante pode carregar depois. Definir isso é papel de produto.
Vale perguntar: quantos sistemas essa tela chama? Dá para mostrar algo na hora e carregar o restante depois?
Conclusão
Latência é decisão de produto, não só técnica. Alinhar o que é “na hora” e o que é “pode ser depois” evita frustração do usuário e expectativa errada.