Latência: O que é e como pode prejudicar uma aplicação

Leonardo Barreto — Thu, 12 Feb 2026 22:14:07 +0000

Um problema que sempre nos deparamos quando temos um software de grande demanda de usuários e integrações com outros sistemas é a latência de respostas, que é um tempo de delay nas respostas de requisições HTTP, ou em uma query rodando no banco de dados. Esse “delay” pode parecer algo normal e que sempre está presente, porém quando temos estruturas mal planejadas ou queries não otimizadas esse tempo de latência aumenta, e então nos deparamos com uma lentidão enorme no sistema, causando a abertura de novos chamados pelo cliente e até usuário parando de usar o sistema, o que causa um impacto direto no financeiro da sua empresa. Onde de acordo com um artigo divulgada pela Amazon em 2008 menciona que a cada 100ms de latência pode impactar em 1% das vendas.

Sabemos então o que é a latência e como ela pode impactar negativamente um sistema, mas como identificar qual a real latência do sistema? Para isso podemos aplicar um padrão chamado Long Tail Latency, uma forma de observar o real impacto para os usuários.

Para criar um gráfico de Long Tail Latency, precisamos analisar alguns dos processos mais utilizados no sistema, onde no meu caso utilizei como dado amostral 20 queries distintas, e então anotamos seus tempos.

Agora organizando esses dados de forma crescente podemos começar a descobrir os pontos que chamamos de: p50, p75, p90, p99, p99.9. Que indicam respectivamente o tempo médio de latência de uma query, as 25% das queries mais lentas, os 10% das queries mais lentas, até chegarmos a casos extremos que seriam o 0,1% das queries do sistema. Para o p50 podemos utilizar a mediana que descobrimos com base na nossa amostra, para os demais pontos, podemos utilizar a seguinte formula:

(ponto ÷ 100) × Total de amostras = posição

Dessa forma descobriremos os pontos de latência para cada cenário.

E por fim podemos criar um gráfico para podermos analisar melhor o que esses dados representam.

Analisando os resultados do teste:

Podemos analisar com o gráfico de percentual de latência que na média o usuário tem uma latência de 188ms de respostas de cada queries que rodam no sistema. Porém vemos como é exponencial o aumento do tempo de resposta, onde as 25% das queries mais lentas do sistema demora 1,3 segundos para rodar, e caso olharmos os piores cenários, temos uma latência de 6 segundos ou mais, o que está muito longe de um cenário ideial.

Portanto com esses dados em mãos podemos criar planos de ação para curto, médio e longo prazo e tomar decisões mais assertivas para a evolução do sistema. Como implementar algoritmos de cache, refatorar códigos repetitivos ou até mesmo planejar uma arquitetura mais performática e eficiente, garantindo facilidade de manutenção e feedbacks mais positivos do cliente final.

Autenticação Stateful x Stateless

Leonardo Barreto — Wed, 18 Sep 2024 00:35:56 +0000

Arquitetura Stateless e Stateful

Refere-se ao estado da aplicação, ou seja, à condição ou qualidade dela em um determinado momento. Em uma autenticação stateless, não existe uma sessão ou usuário armazenado, contendo apenas conteúdos estáticos. Isso difere do stateful, que se trata de um conteúdo dinâmico.

Um processo stateless é um recurso isolado, que não faz referência a nenhum outro serviço ou interação com outro sistema. Ele opera apenas naquela parte do código, sem trazer informações de transações antigas, pois a autenticação stateless não armazena esse tipo de dado; cada operação é feita do zero.

A autenticação stateful permite que as informações sejam utilizadas mais de uma vez e são executadas com base no contexto das transações anteriores. Por isso, em aplicações onde se necessita aguardar uma resposta ou um dado preexistente, seja ele presente em outro sistema ou base de dados, utiliza-se o stateful.

Autenticação Stateless

A autenticação stateless consiste em uma estratégia na qual, após informar as credenciais, o usuário recebe um token de acesso como resposta. Esse token já contém todas as informações necessárias para identificar o usuário que o gerou, sem a necessidade de consultar continuamente o serviço que emitiu o token ou uma base de dados.

Esse token é armazenado do lado do cliente (navegador), de modo que o servidor só tem a capacidade de verificar a validade do token, confirmando se o payload e a assinatura correspondem.

JWT de autenticação Stateless

JSON Web Token (JWT) são chaves com padrões estabelecidos na RFC-7519, contendo uma entidade em forma de declarações, que são independentes, sem a necessidade de chamar o servidor para revalidar o token.

São strings codificadas no padrão base64 por meio de uma secret key, como no exemplo:

Vantagens e Desvantagens

Vantagens:

Baixo consumo de memória do servidor.
Excelente em termos de escalabilidade.
Ideal para aplicações distribuídas, como APIs e microsserviços.
Geração e distribuição do token em uma aplicação isolada, sem dependência de terceiros.
Facilidade na interpretação e validação dos dados do usuário do token.

Desvantagens:

Dificuldade no controle de acesso.
Não é possível revogar o token a qualquer momento com facilidade.
Pode facilitar a entrada de terceiros mal-intencionados, caso alguém tenha acesso ao token.
A sessão não pode ser alterada até a expiração do token.
O token JWT é mais complexo e pode se tornar desnecessário em aplicações centralizadas, como monolitos.

Autenticação Stateful

Comumente utilizada em várias aplicações, principalmente naquelas que não exigem tanta escalabilidade, a sessão com estado é criada no back-end da aplicação, e a referência da sessão é enviada de volta ao usuário correspondente. Cada vez que o usuário faz uma requisição, uma parte da aplicação gera o token. A partir desse momento, a cada nova requisição, esse token será enviado novamente para a aplicação para revalidar o acesso. Nesse modelo, caso haja alguma alteração nos dados do usuário, o token pode ser facilmente revogado.

São tokens de acesso opacos, ou seja, uma string simples de formato proprietário que não contém qualquer identificador ou dado do usuário referente àquele token. O destinatário precisa chamar o servidor que criou o token para validá-lo.

Exemplo de token: 8c90e55a-e867-45d5-9e42-8fcbd9c30a74

Esse ID deve ser armazenado em alguma base de dados junto ao usuário proprietário do token.

Vantagens e Desvantagens

Vantagens:

Lógica de implementação centralizada.
Gestão e controle de acesso simplificados.
Excelente para monolitos, aplicações MVC e processos internos.
Mais seguro contra terceiros mal-intencionados.

Desvantagens:

Pode ocorrer uma sobrecarga na API responsável por validar o token.
Falha no quesito escalabilidade.
Maior dificuldade em distribuir a autenticação entre microsserviços.
Em uma aplicação distribuída, caso o serviço de autenticação falhe, todos os outros serviços ficam indisponíveis.
Maior complexidade de implementação.
Maior dificuldade de integração com sistemas de terceiros.

Quando utilizar cada abordagem?

Quando utilizar um Token JWT e Autenticação Stateless

Quando é necessária maior performance sem a preocupação com a sobrecarga de uma API.
Quando se tem várias comunicações distribuídas entre serviços.
Quando é preciso identificar qual usuário está realizando uma ação no sistema em diferentes serviços.
Quando não se pretende persistir dados de um usuário, apenas seu registro inicial.
Se for preciso gerar acessos externos ao serviço.
Se for necessário manipular os dados de quem está realizando uma determinada ação com o mínimo de impacto no sistema.

Quando utilizar um Token Opaco e Autenticação Stateful

Se for necessário o controle total de acesso dos usuários de um sistema, principalmente para definição de hierarquia de acesso.
Em uma aplicação centralizada, sem serviços distribuídos e sem comunicação com serviços externos.

Considerações Finais:

Em alguns trechos, como "estrese da API", o termo pode ser substituído por "sobrecarga da API" para maior clareza.
A seção sobre "Token JWT" poderia incluir uma explicação mais detalhada sobre o que são as "declarações" mencionadas na RFC-7519, caso o público-alvo precise de mais contexto.
Na seção sobre autenticação stateful, a frase "uma parte de aplicação irá gerar o token" poderia ser esclarecida explicando qual parte específica da aplicação é responsável por isso.

Forem: Leonardo Barreto

Latência: O que é e como pode prejudicar uma aplicação

Analisando os resultados do teste:

Autenticação Stateful x Stateless

Arquitetura Stateless e Stateful

Autenticação Stateless

JWT de autenticação Stateless

Vantagens e Desvantagens

Autenticação Stateful

Vantagens e Desvantagens

Quando utilizar cada abordagem?

Quando utilizar um Token JWT e Autenticação Stateless

Quando utilizar um Token Opaco e Autenticação Stateful

Considerações Finais: