DEV Community: Stephanto

JWT ou sessão? Como cada um funciona e quando usar qual

Stephanto — Tue, 20 Oct 2026 20:24:57 +0000

Começa por aqui: você clica em "Sair". Na sessão, você fica fora na hora. No JWT, o token continua valendo até expirar.

Parece detalhe, mas essa diferença diz muito sobre como cada um funciona. Estudei sobre o assunto e quero compartilhar com vocês, afinal a melhor forma de aprender é ensinando. No fim do artigo você vai saber como cada um funciona, o preço de cada um e quando usar qual.

É um conteúdo introdutório, a ideia é simplificar. O contexto: numa conversa com o tech lead, veio a pergunta "JWT ou sessão?". Como era uma aplicação web, a escolha foi sessão. Este artigo é pra entender o porquê dessa resposta, e quando ela seria outra.

O problema: o HTTP não lembra de você

O HTTP, protocolo da web, é stateless: ele não lembra de nada entre uma requisição e outra. Cada requisição chega "do zero".

Por exemplo, você loga no e-mail e clica numa mensagem. Pro servidor, esse clique chega sem nenhuma memória do login que você acabou de fazer. Ou seja, depois que você digitou e-mail e senha, alguma coisa precisa viajar em toda requisição seguinte dizendo "sou eu, já fiz login".

E essa "coisa" é valiosa. A OWASP (a comunidade que mantém os guias de segurança web mais usados) lembra que, depois do login, o identificador da sessão vale temporariamente o mesmo que a credencial mais forte que o usuário usou. Quem rouba esse identificador vira o usuário, e isso se chama session hijacking (sequestro de sessão).

Existem dois jeitos principais de resolver isso: Sessão e JWT.

Um aviso antes de começar: é comum ver a comparação "cookie vs JWT", mas isso é comparar maçã com laranja. Cookie é um lugar de guardar coisa no navegador; JWT é um formato de token. As comparações certas são sessão vs JWT (onde fica o estado) e cookie vs localStorage (onde o navegador guarda).

Sessão: o servidor guarda, o navegador leva só um número

Na Sessão, o servidor guarda quem está logado num lugar dele: na memória, num banco ou num banco em memória como o Redis. Esse lugar é o session store.

Pro navegador, ele devolve só um número aleatório, o session ID, dentro de um cookie: um espaço do navegador que vai junto em toda requisição para aquele site, sozinho, sem o JavaScript fazer nada.

Na prática, a conversa entre navegador e servidor fica mais ou menos assim:

POST /login
(e-mail + senha)

HTTP/1.1 200 OK
Set-Cookie: session_id=abc123; Secure; HttpOnly; SameSite=Lax; Path=/

E a partir daí, em toda requisição:

GET /emails
Cookie: session_id=abc123

Do lado do servidor, cada requisição faz uma consulta ao session store. De forma simplificada:

// pseudocódigo
const sessionId = request.cookies.session_id   // "abc123"
const sessao = await sessionStore.get(sessionId)

if (!sessao) {
  return responder(401)                          // sessão inválida: volta pro login
}

const usuario = sessao.usuario                   // "Vinicius"
return responder(200, buscarEmails(usuario))

A analogia do guarda-volumes

Pensa num guarda-volumes: você entrega a mochila e recebe uma ficha com um número.

A ficha é o session ID, a mochila são os seus dados e o balcão é o servidor. A ficha sozinha não diz nada, quem sabe o que tem atrás dela é o balcão.

O cookie da sessão

Como o session ID viaja em cookie, a segurança dele depende dos atributos que vêm junto no Set-Cookie:

HttpOnly: o JavaScript da página não consegue ler o cookie. Ajuda contra XSS (quando um atacante consegue rodar JavaScript dele dentro do seu site).
Secure: o cookie só vai por HTTPS.
SameSite: controla se o cookie vai junto em requisições que vêm de outro site. Strict nunca vai; Lax vai também quando o usuário navega pro seu site vindo de outro (clicou num link); None vai sempre (e exige Secure).

A OWASP também recomenda trocar o session ID por cookie, e não por parâmetro na URL, porque na URL ele vaza em log, histórico e favoritos. O exemplo que ela dá para um cookie de sessão é:

Set-Cookie: __Host-SessionID=<value>; Secure; HttpOnly; SameSite=Strict; Path=/

O lado bom: sair é apagar o registro

O logout é simples: o servidor apaga o registro abc123 do session store. Na próxima requisição, a consulta não encontra nada e você já está fora. É o 401 da imagem lá de cima.

O mesmo vale pra "sair de todos os dispositivos" ou pra tirar a permissão de admin de alguém: como o servidor consulta a sessão a cada requisição, a mudança vale na hora.

Porém, nem tudo são flores: CSRF

O cookie ir sozinho em toda requisição é o ponto forte da sessão e também o ponto fraco.

Como o cookie vai sozinho, outro site pode fazer seu navegador mandar uma ação com ele. Isso é o CSRF (Cross-Site Request Forgery, ou falsificação de requisição entre sites).

Vamos com o exemplo clássico da PortSwigger pra entender melhor: um site tem um POST /email/change que troca o e-mail da conta, e identifica o usuário só pelo cookie de sessão. O atacante monta uma página com um formulário escondido apontando pra esse endereço, com o e-mail dele e um script que envia o formulário sozinho. Você, logado, abre essa página, o navegador manda o cookie junto e o seu e-mail é trocado. Depois é só o atacante pedir "esqueci minha senha" pra tomar a conta.

O CSRF tem defesa conhecida:

SameSite no cookie, que segura o cookie em pedidos vindos de outro site.
Um token aleatório no formulário (o synchronizer token pattern): o servidor gera um valor imprevisível, coloca no formulário e confere em todo POST. O site do atacante não tem como adivinhar esse valor.

A OWASP trata o SameSite como defesa em profundidade e, na maioria dos casos, não como substituto do token.

Outro custo: o estado fica no servidor

Toda requisição consulta o lugar onde as sessões ficam. É uma ida a mais na rede a cada clique.

E com mais de um servidor atrás de um load balancer, a sessão criada no servidor A não existe no servidor B se ela estiver na memória dele. Por isso, quando a aplicação cresce, o comum é usar um store compartilhado, como um Redis dedicado às sessões.

E aí vem a pergunta: e se o próprio token carregasse quem você é?

JWT: os dados vão no próprio token

É isso que o JWT (JSON Web Token, definido na RFC 7519) faz.

No JWT, o servidor assina o token com uma chave secreta que só ele tem e entrega pro cliente. Em toda requisição, o token vai junto num campo da requisição, o header Authorization:

GET /emails
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

O servidor só confere a assinatura, sem consultar banco nenhum. Isso é o que chamam de autenticação stateless.

"Bearer" quer dizer "portador": qualquer um que tiver o token pode usar, sem provar mais nada. Ou seja, um JWT vazado vale tanto quanto um cookie de sessão vazado.

E um detalhe interessante: o navegador não anexa o header Authorization sozinho, quem coloca é o código da aplicação. Por isso, um JWT enviado nesse header não sofre CSRF do jeito que o cookie sofre.

Por dentro do token

Por dentro, o token tem 3 partes separadas por ponto:

Header: como foi assinado (o algoritmo).
Payload: os dados, como o seu id, a sua permissão e quando expira.
Signature: a assinatura.

Este é o token da imagem:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjMiLCJyb2xlIjoiYWRtaW4iLCJleHAiOjE3OTI1MzcyMDB9.5D9T1LnD3PpUHNJxm8pq_sny42svPgUxKkkpA8ZSnsQ

Decodificando as duas primeiras partes, sem chave nenhuma, dá:

// Header
{
  "alg": "HS256",  // como foi assinado
  "typ": "JWT"     // é um JWT
}

// Payload
{
  "sub": "123",       // quem é você (id 123)
  "role": "admin",    // a permissão, criada pela aplicação
  "exp": 1792537200   // quando expira, em segundos desde 1970
}

Repare: Header e Payload são só base64url, uma codificação, não criptografia. Qualquer um lê. Dá pra testar no terminal:

echo 'eyJzdWIiOiIxMjMiLCJyb2xlIjoiYWRtaW4iLCJleHAiOjE3OTI1MzcyMDB9' | base64 -d
# {"sub":"123","role":"admin","exp":1792537200}

Esse comando só funciona direto aqui porque esse trecho não precisa de padding. Em geral, troque -_ por +/ e complete com = antes de decodificar.

Ou seja, a assinatura protege o token contra alteração, não contra leitura. Se alguém trocar "role":"user" por "role":"admin", a assinatura não bate mais e o servidor recusa. Mas nada de colocar segredo no payload.

A analogia do crachá

Pensa num crachá com seu nome, cargo e validade, carimbado pela empresa.

O crachá é o JWT e o carimbo é a assinatura: qualquer porteiro confere e libera, sem ligar pra ninguém. O problema é que o porteiro não tem como saber se você foi demitido ontem.

O problema central do JWT: ele vale até expirar

Esse é o ponto principal: o JWT vale até expirar, não importa o quê. O servidor não guarda nada sobre os tokens que emitiu, então não tem o que apagar.

Clicou em "Sair"? O token continua valendo. É o 200 da imagem lá de cima.
Tirou o admin de alguém? O token antigo segue dizendo "role":"admin" até vencer.
Detectou uma invasão? O token do atacante também segue válido.

As mitigações (e o custo delas)

Dá pra contornar, mas cada saída tem um preço:

Token curto + refresh token: o token que vai em toda requisição (o access token) vive pouco. Pra pegar outro, o cliente usa um refresh token, um segundo token que, pela RFC 6749 (OAuth 2.0), serve só pra pedir novos access tokens.
Lista de bloqueio (denylist): guardar os tokens revogados e conferir em toda requisição.

Mas aí o servidor volta a guardar estado: precisa guardar os refresh tokens, ou consultar a lista de bloqueio a cada requisição. A própria OWASP diz que, se você usa JWT como sessão, vai precisar de um jeito de invalidar, e aí a sessão deixa de ser stateless, o que pode acabar com a vantagem.

Onde guardar o JWT no navegador?

Aqui aparece um dilema que a sessão não tem:

localStorage: o JavaScript lê à vontade. A OWASP recomenda não guardar tokens de autenticação ali, porque um único XSS vaza todos eles.
Cookie HttpOnly: protege contra XSS, mas aí o navegador manda o cookie sozinho e você volta a ter CSRF. Na prática, vira um cookie de sessão mais pesado.

Um risco extra: quem escolhe o algoritmo?

Lembra do header, que diz o algoritmo? Ele vem do cliente, e ainda não foi validado quando o servidor lê ele. Se a biblioteca confia no alg, é o atacante quem escolhe como a assinatura vai ser verificada.

Em 2015, o pesquisador Tim McLean achou bibliotecas de JWT aceitando "alg":"none", ou seja, um token sem assinatura sendo tratado como se a assinatura tivesse sido verificada. O ataque é trocar o header, mudar o payload pro que quiser e deixar a assinatura vazia:

// Header forjado
{ "alg": "none", "typ": "JWT" }

// Payload forjado
{ "sub": "123", "role": "admin" }

No pacote jsonwebtoken (Node.js), um erro parecido, na validação do tipo de algoritmo (aceitar HS256 quando esperava RS256), virou a falha CVE-2015-9235, com nota 9.8 de 10 no NVD. As versões 4.2.1 e anteriores eram afetadas, e a correção veio na 4.2.2.

A defesa: o servidor fixa o algoritmo. A RFC 8725 (boas práticas de JWT) pede que a biblioteca deixe você dizer quais algoritmos aceita, e não use nenhum outro. De forma simplificada:

// pseudocódigo

// errado: deixa o token escolher o algoritmo
verificar(token, chave)

// certo: o servidor já sabe qual algoritmo usa
verificar(token, chave, { algoritmos: ["HS256"] })

Com sessão esse problema não existe: o servidor só compara um ID aleatório, não tem algoritmo pra escolher errado.

Quando usar cada um?

Não é regra, cada caso é um caso. Mas uma pergunta ajuda: quem é o cliente?

Navegador falando com o seu backend: normalmente sessão. O navegador já manda o cookie sozinho, o HttpOnly protege contra XSS, o logout vale na hora e o CSRF tem defesa conhecida. A própria Auth0 indica cookie nesse cenário: quando o frontend só chama uma API num domínio que compartilha cookie com ele, não precisa de token nenhum.

App mobile, outro serviço ou SSO: normalmente JWT.

App mobile: não tem o cookie automático do navegador, então um token curto no Authorization + refresh token é o caminho comum.
Outro serviço: um serviço confere a assinatura do token sozinho, sem precisar chamar ninguém.
SSO (Single Sign-On, logar uma vez e entrar em vários sistemas): no OpenID Connect, o ID Token, que diz quem é o usuário, é um JWT pela própria especificação.

E dá até pra usar os dois na mesma aplicação: sessão pro navegador, JWT curto pro app e pros serviços. Foi por isso que, numa aplicação web, a resposta pro tech lead foi sessão.

Resumindo

O HTTP esquece você a cada requisição.
Sessão: o servidor guarda, o cookie leva só um número.
JWT: os dados vão no token, assinados e legíveis.
Sessão sai na hora, JWT vale até expirar.
Em geral, navegador: sessão. Mobile, serviços e SSO: JWT.

Conclusão

Apresentei apenas algo introdutório, recomendo se aprofundarem! Cada caso é um caso, e não existe vencedor absoluto: cada um é certo pro seu tipo de cliente.

Pra quem já é experiente: no seu último projeto vocês foram de sessão ou JWT, e por quê? Conta nos comentários.

Obrigado por ler até aqui!

Esse artigo nasceu de uma thread que publiquei no X. Se preferir a versão curta, com os diagramas, é só dar uma olhada lá.

Fontes

O que fazer quando seu banco de dados não aguenta mais? Uma introdução ao Sharding

Stephanto — Fri, 16 Oct 2026 14:40:02 +0000

Empresas como Notion, Slack e Discord passaram por isso e usaram a mesma técnica: o sharding. Estudei sobre o assunto e quero compartilhar com vocês de forma simples, afinal a melhor forma de aprender é ensinando.

O cenário: o banco não aguenta mais

Seu sistema cresceu, o banco ficou lento e as escritas começam a engasgar. O primeiro reflexo é comprar uma máquina maior, com mais CPU, mais memória e disco mais rápido. Isso se chama escala vertical, ou seja, crescer "para cima".

Porém, nem tudo são flores. A escala vertical tem um teto: em algum momento não existe máquina maior para comprar. Além disso, fica cada vez mais caro, e se essa única máquina cair, cai tudo junto. É o famoso ponto único de falha.

"Mas e as réplicas?"

Réplicas são cópias do banco e ajudam muito na leitura, porque espalham as consultas. Porém, toda escrita continua indo para um único banco principal. Se o gargalo é escrita ou volume de dados, réplica não resolve.

O que é sharding

Em vez de uma máquina maior, você usa várias máquinas, e cada uma guarda só uma parte dos dados. Cada parte é chamada de shard. Todas têm as mesmas tabelas, mas linhas diferentes. Ou seja, escala horizontal.

Por exemplo, um app com 3 milhões de usuários. A shard key (já explico o que é) é o id do usuário: ids de 1 a 1 milhão vão para o shard 1, de 1 a 2 milhões para o shard 2 e de 2 a 3 milhões para o shard 3.

É como uma biblioteca que lotou e abriu unidades: autores de A a M na unidade 1, de N a Z na unidade 2. Achar um livro pelo autor é fácil. Mas achar "todos os livros de 2020" obriga a visitar todas as unidades. Guarda essa ideia, porque ela é o coração dos problemas do sharding.

Sharding, particionamento e replicação

Três termos que confundem muito:

Particionamento: dividir uma tabela em pedaços, geralmente no mesmo servidor. Por exemplo, o partitioning nativo do PostgreSQL.
Sharding: dividir os dados entre servidores diferentes.
Replicação: fazer cópias iguais dos dados em vários servidores.

Ou seja, sharding ajuda a escalar escrita e volume, e replicação ajuda a escalar leitura e disponibilidade. E eles andam juntos: na prática, cada shard costuma ter as suas próprias réplicas. Um não substitui o outro.

Como o sistema sabe onde está cada dado?

Se os dados estão espalhados, alguém precisa encaminhar a consulta para o shard certo. Isso pode ficar:

No código da aplicação, que calcula o shard.
Num intermediário, como o Vitess, que nasceu no YouTube e é usado pelo Slack.
No próprio banco, como o sharding nativo do MongoDB ou o Citus no Postgres.

No MongoDB, por exemplo, a aplicação fala com o roteador mongos, que consulta os metadados nos config servers e manda a query para o shard certo.

A shard key: a decisão mais importante

A shard key é a coluna que decide em qual shard cada linha vai morar. Uma boa chave tem muitos valores diferentes, distribui os dados por igual e aparece em quase toda consulta. Por exemplo, o id do usuário.

Por faixa (range)

Ids de 1 a 1 milhão no shard A, de 1 a 2 milhões no shard B. É ótima para buscar intervalos. Mas se a chave for a data, toda escrita de hoje cai no mesmo shard, que fica sobrecarregado.

Por hash

O sistema passa a chave por uma função matemática (algo como hash(user_id) % N) que espalha os dados por igual entre os shards. Distribui muito bem. Porém, buscar um intervalo vira perguntar para todos os shards e juntar a resposta.

Por região ou por cliente

Também dá para separar por região, deixando os dados perto do usuário, ou por cliente. Por exemplo, o Notion dividiu o banco pelo id do workspace. Assim, os dados de uma mesma empresa ficam juntos e quase toda consulta vai para um shard só.

Dica: shards lógicos

Uma dica que o Notion usou: crie muito mais shards "lógicos" do que máquinas. Eles começaram com 480 shards em 32 bancos. É como uma mudança: você empacota tudo em 480 caixas. Se trocar 32 armários por 64, move caixas inteiras, sem desempacotar livro por livro.

Os problemas

Lembra das unidades da biblioteca? Consultas que cruzam shards, como JOINs e relatórios gerais, precisam perguntar para todos e juntar o resultado na aplicação. E transações envolvendo vários shards ficam caras e complicadas.

Outros problemas:

Ids: o auto-incremento de cada shard pode repetir o mesmo número.
Shard "quente": um cliente muito ativo concentra a carga. O Discord conta isso no post sobre como guarda trilhões de mensagens.
Resharding: mudar os dados de shard com o sistema no ar é a parte mais arriscada.

Então quando usar?

Só depois de tentar o mais simples: melhorar queries e índices, colocar cache, réplicas de leitura e uma máquina maior. E quando o problema é escrita ou volume que não cabe mais num servidor. Sharding cedo demais é complexidade de graça.

Ou seja, sharding resolve o limite de um banco só, mas cobra em complexidade para sempre, na aplicação e na operação. E sempre que possível, prefira ferramentas que já fazem isso por você (Vitess, Citus, MongoDB) em vez de reinventar.

Conclusão

Apresentei apenas algo introdutório, recomendo se aprofundarem! Se você já é experiente, complementa nos comentários. Obrigado por ler até aqui!

Fontes

Cache e CDN são a mesma coisa?

Stephanto — Wed, 14 Oct 2026 12:06:26 +0000

Muita gente usa os dois termos como sinônimos, mas não são. Estudei sobre isso e quero compartilhar com vocês, afinal a melhor forma de aprender é ensinando.

O que é cache

De forma simples, cache é guardar uma cópia de um dado em um lugar mais rápido ou mais perto de quem vai usar, para não precisar buscar de novo na fonte original. Ou seja, você troca espaço (memória ou disco) por velocidade.

Repare que cache é um conceito, não uma ferramenta. Existe cache na CPU, no navegador, no servidor, no banco de dados. E ele funciona porque a gente acessa sempre os mesmos dados: um post viral, o perfil do usuário logado, o logo do site.

Hit e miss

Hit: o dado estava no cache, e a resposta sai rápido.
Miss: não estava, então é preciso buscar na fonte original e, normalmente, salvar no cache para a próxima vez.

Num artigo aqui do dev.to com Node + Redis, a primeira requisição (miss, que foi buscar numa API externa) levou 615 ms. A mesma requisição depois de cacheada (hit) levou 3 ms.

TTL (Time To Live)

TTL é quanto tempo um dado vale antes de expirar. Por exemplo, se guardo o perfil de um usuário por 5 minutos e ele troca a foto, os outros podem continuar vendo a foto antiga por até 5 minutos. TTL curto deixa o dado mais fresco, mas gera mais misses; TTL longo dá mais hits, com mais chance de mostrar dado velho.

As camadas de cache

Entre o usuário e o banco de dados existem várias camadas de cache, e cada uma guarda coisas diferentes:

Navegador
CDN
Reverse proxy (NGINX, Varnish)
Cache de aplicação (Redis, Memcached)
O próprio banco de dados

Cache-aside

A estratégia mais comum no cache de aplicação é o cache-aside. A aplicação olha primeiro no cache; se der miss, busca no banco, salva no cache e devolve. Num e-commerce, quem abre primeiro o "Tênis X" paga a ida ao banco, e os próximos milhares recebem do Redis.

Nem tudo são flores

"Há só duas coisas difíceis em Ciência da Computação: invalidação de cache e dar nomes às coisas." (frase atribuída a Phil Karlton)

Invalidação. Quando o dado muda na fonte, como fazer o cache esquecer a versão velha?

Cache stampede. Imagine a página inicial de um site de notícias com TTL de 60 segundos. No segundo 61 a chave expira, milhares de requisições dão miss juntas e todas batem no banco. O banco pode cair.

Cachear o que não devia. O erro mais perigoso é guardar num cache compartilhado (proxy ou CDN) uma página com dado de usuário logado. O usuário A abre "Minha conta", a resposta fica cacheada e o usuário B recebe a página com os dados do A. Para isso existe o Cache-Control: private.

O que é CDN

CDN (Content Delivery Network) é uma infraestrutura: uma rede de servidores espalhados pelo mundo que guardam cópias do seu conteúdo perto do usuário. Exemplos: Cloudflare, Amazon CloudFront, Akamai e Fastly.

O problema que ela resolve é físico. O dado viaja por cabos, e distância é latência. Se seu servidor está nos EUA e o usuário está em Manaus, cada imagem, CSS e JS faz essa viagem de ida e volta. Com uma CDN, ele baixa tudo de um servidor no Brasil.

Como funciona

O usuário acessa meusite.com/logo.png e o DNS manda ele para o servidor da CDN mais próximo, o PoP (Point of Presence). Se o PoP tem o arquivo, entrega na hora. Se não tem, busca no seu servidor (a origem), entrega e guarda para os próximos.

Quem diz o que a CDN pode guardar, e por quanto tempo, são os headers que a origem manda:

Cache-Control: public, max-age=31536000, immutable permite guardar por um ano (bom para arquivos com hash no nome).
Cache-Control: private proíbe a CDN de guardar.
ETag e Last-Modified permitem perguntar "mudou?" e receber um 304 Not Modified sem baixar de novo.

Um exemplo grande é a Netflix, que tem a própria CDN, a Open Connect. Ela coloca servidores dentro dos provedores de internet, e o site oficial fala em mais de mil provedores parceiros. Ou seja, a série que você assiste provavelmente vem de dentro do seu provedor.

Então, qual a diferença?

Cache é o conceito; CDN é uma aplicação dele em escala geográfica.
O Redis fica perto do servidor; a CDN fica perto do usuário.
A CDN resolve distância, mas não resolve query lenta no banco.

E eles não são concorrentes: a maioria dos sistemas grandes usa os dois.

Use cache de aplicação para queries pesadas e repetidas, sessões e dados lidos muito e mudados pouco.

Use CDN para usuários espalhados pelo mundo, imagens, JS, CSS, vídeo e picos de tráfego.

Quando NÃO usar cache

Dado que precisa estar sempre certo na leitura, como saldo ou estoque na hora do pagamento.
Dado que muda o tempo todo e quase não se repete.
No começo do projeto, sem gargalo medido: cache cedo demais esconde problema de query.

Conclusão

Apresentei apenas algo introdutório, recomendo se aprofundarem! Se você já é experiente, complementa nos comentários. Obrigado por ler até aqui!

Fontes

Pirâmide de Testes: Do Unitário ao E2E - Introdução

Stephanto — Mon, 02 Jun 2025 21:44:35 +0000

Olá, comunidade dev! 👋 Se você busca desenvolver software com mais qualidade e confiança, entender a Pirâmide de Testes é fundamental. Popularizada por Mike Cohn, essa abordagem nos ajuda a organizar e priorizar os diferentes tipos de testes em nossos projetos.

Neste artigo, vamos mergulhar nas suas camadas – Unitários, Integração e End-to-End (E2E) – e desvendar o valor e o custo de cada uma. Preparados? 🚀

As Camadas da Pirâmide: Uma Visão Geral

A pirâmide é visualmente dividida em três camadas principais, cada uma com um papel específico e diferentes trade-offs:

🧱 Testes Unitários: A base sólida.
🔗 Testes de Integração: A conexão entre as partes.
🎯 Testes End-to-End (E2E): A validação da experiência completa.

Vamos explorar cada uma delas.

Testes End-to-End (E2E): Validando a Experiência do Usuário 🎯

No topo da pirâmide, os testes E2E simulam a jornada completa de um usuário real interagindo com sua aplicação. Pense em um teste de cadastro: o script abriria o site, preencheria os campos, submeteria o formulário e verificaria o resultado, passando pelo frontend, backend, banco de dados e qualquer outro serviço envolvido.

Valor do E2E:

Máximo para o Negócio: Garante que a funcionalidade crítica está operando como esperado do início ao fim, sob a perspectiva do usuário. ✅
Alta Confiança: Um conjunto de testes E2E bem-sucedido transmite grande confiança sobre a saúde geral da aplicação.

Custo do E2E:

Altíssimo: São os testes mais caros para desenvolver, manter e executar. 💸
Depuração Complexa: Identificar a causa raiz de uma falha pode ser demorado, já que muitos componentes estão envolvidos.
Ambiente Exigente: Requerem um ambiente de testes o mais fiel possível ao de produção, o que pode ser custoso e complexo de configurar.

Testes Unitários: A Fundação Sólida 🧱

Na base da pirâmide, os testes unitários focam na menor unidade de código isolável: uma função, um método ou uma classe pequena. O objetivo é simples: para uma entrada X, esperamos uma saída Y. Testamos diversos cenários, incluindo caminhos felizes e casos de exceção.

### Mocks ao Resgate!

Um erro comum é achar que testes unitários precisam acessar o banco de dados ou outros serviços externos. Pelo contrário! Para garantir isolamento e rapidez, usamos mocks (objetos simulados) para representar essas dependências.

Custo dos Unitários:

Baixíssimo: São baratos para escrever, executar e manter. ⚡️
Feedback Rápido: Executam em milissegundos, fornecendo feedback quase instantâneo aos desenvolvedores.
Depuração Fácil: Quando um teste unitário falha, o problema geralmente está contido na pequena unidade testada.

Valor dos Unitários:

Menor Valor Isolado (para o Negócio): Sozinhos, não garantem que a aplicação inteira funcione. Muitas unidades funcionando perfeitamente em isolamento podem falhar ao serem integradas. 🧩
Base Crucial para a Qualidade: Apesar disso, são a fundação! Ajudam a garantir que cada "tijolo" da sua aplicação é confiável.
Guia de Design: Incentivam um bom design de código (baixo acoplamento, alta coesão) e revelam problemas como falta de abstração ou injeção de dependência inadequada.
Documentação Viva: Descrevem como cada unidade de código deve se comportar.
Grande Quantidade: São os testes mais numerosos em uma codebase saudável.

Testes de Integração: Conectando os Pontos 🔗

Localizados no meio da pirâmide, os testes de integração verificam se diferentes unidades ou componentes do sistema se comunicam e colaboram corretamente. Se os testes unitários garantem que os tijolos são bons, os de integração garantem que eles se encaixam.

Aqui, pode ser válido interagir com um banco de dados real (geralmente em uma instância de teste, de menor escala) ou outros serviços externos para validar essa comunicação.

Valor da Integração:

Médio: Fornecem uma boa visão para os desenvolvedores sobre como diferentes partes da aplicação interagem e como os recursos são utilizados.
Confiança na Colaboração: Aumentam a confiança de que os módulos principais funcionam bem juntos.
Indicador de Saúde: Embora não representem a experiência final do usuário, dão um bom panorama do estado da aplicação.

Custo da Integração:

Médio: São mais caros e lentos que os testes unitários, pois envolvem múltiplos componentes.
Depuração Moderada: Identificar falhas pode ser mais complexo que nos testes unitários, mas geralmente mais simples que nos E2E.
Recursos: Podem exigir mais recursos de setup (ex: um banco de dados de teste) do que os unitários.

Por Que o Formato de Pirâmide? 🔺

O formato visual da pirâmide não é um acaso. Ele ilustra a proporção ideal de cada tipo de teste em um sistema saudável e com manutenção sustentável:

Base Larga (Muitos Testes Unitários): São rápidos, baratos e isolam falhas eficientemente. Constituem a maior parte da sua suíte de testes.
Meio (Menos Testes de Integração): Verificam as interações chave sem o custo dos E2E.
Topo Estreito (Poucos Testes E2E): Cobrem os fluxos críticos do usuário, mas são usados com moderação devido ao seu alto custo.

Seguir essa proporção ajuda a obter feedback rápido (a maioria dos testes são rápidos), custos de manutenção controlados e uma cobertura de risco eficaz.

Pontos de Atenção e Nuances 📝

Contexto é Rei: Os exemplos e proporções são um guia, não uma regra absoluta. Adapte a estratégia ao seu produto e contexto. Um teste E2E para uma API é diferente de um para uma aplicação web full-stack.
Integração no Frontend: Testes de integração não são exclusivos do backend! No frontend, eles podem verificar a interação entre componentes da UI, por exemplo.
Estratégia Balanceada: O objetivo final é ter uma estratégia de testes balanceada, que maximize a confiança e minimize os custos e o tempo de feedback. ⚖️

Concluindo...

A Pirâmide de Testes é um modelo poderoso para guiar sua estratégia de testes, ajudando a construir aplicações mais robustas, confiáveis e fáceis de manter. Lembre-se que testes são um investimento na qualidade e sustentabilidade do seu software!

E você, como aplica a Pirâmide de Testes nos seus projetos? Quais são seus maiores desafios ou aprendizados? Compartilhe nos comentários abaixo! 👇

Entendendo a Replicação de Banco de Dados: Uma Chave para Sistemas Robustos

Stephanto — Wed, 21 May 2025 19:50:04 +0000

Olá a todos! Estou aqui novamente para compartilhar mais do que aprendi esta semana, especificamente sobre o tema da replicação de dados. Este artigo fornecerá uma explicação resumida do que é e quais são os seus tipos. Vamos lá!

Por Que a Replicação de Dados é Importante?

Para entender a importância da replicação de dados, considere este cenário: Imagine que este é um servidor hospedado na minha casa. Se eu acidentalmente derramar café em cima do servidor/DB, o que acontece? Já era.

Temos aqui um "Single point of failure".

Outro ponto é que usuários de países diferentes têm tempos de resposta diferentes. Dependendo da localização, demora um tempo considerável para obter resposta da aplicação, o que pode prejudicar a experiência do usuário.

Então, a replicação pode servir para, caso algum servidor deixe de funcionar, aumentar a disponibilidade e diminuir a latência para diferentes localidades. Adicionamos mais DBs para poder garantir essas melhorias.

Porém, não sei se vocês notaram, mas surge um novo problema: Temos 3 bancos de dados em 3 lugares diferentes. Como garantir e manter a sincronização entre os 3 bancos de dados?

Abordagens para Consistência de Dados

Ao lidar com múltiplos bancos de dados, garantir a consistência dos dados é crucial. Existem duas abordagens principais:

1. Replicação Síncrona

A primeira abordagem é a Síncrona. Ela garante o dado mais recente (tendo uma consistência forte) através de fazer com que o usuário aguarde, se necessário, todo o processo de replicação para obter a resposta dele. O problema dessa abordagem é que ela gera uma certa lentidão.
![Sincrona]https://pbs.twimg.com/media/GpI_d8sWsAAYR5J?format=jpg&name=4096x4096)

2. Replicação Assíncrona

A outra abordagem é a Assíncrona. Com ela, o usuário não precisa esperar todo o processo de replicação (pois ele é feito em background), o que torna o acesso ao dado mais rápido. Seu problema é que não garante que a consistência seja 100%, e sim a chamada "consistência eventual".

Métodos de Replicação

Agora que vocês sabem as abordagens, vamos para os métodos de replicação. Vou apresentar 3:

Single-leader replication
Multi-leader replication
Leaderless replication

1. Single-Leader Replication

No Single-leader replication, apenas um banco recebe os writes e replica para os outros que apenas recebem reads.

Prós: É bom pois não tem conflitos.
Contras: Porém, tem um Throughput baixo e possui Single point of failure pois só um escreve.
Caso de Uso: É comum de ser usado em aplicações financeiras.

2. Multi-Leader Replication

Já o Multi-leader replication, a replicação de dados ocorre entre os DBs, ou seja, todos são líderes.

Prós: Possui um alto throughput para escritas.
Contras: O que pode gerar conflitos nas escritas.
Caso de Uso: É usado para grandes áreas geográficas.

3. Leaderless Replication

Por fim, o Leaderless replication funciona na forma de "Quorum" para lidas e escritas. Para simplificar, veja a imagem abaixo: Temos 4 nós, se um user quiser ler/escrever, será lido um pouco a mais da metade do número de nós para assim ter a resposta.

Prós: Isso é feito para garantir a consistência, o que gera uma alta disponibilidade.
Contras: Porém, acaba causando conflitos de escrita e gera latência na leitura.
Caso de Uso: É usado em sistemas que priorizam alta disponibilidade e tolerância a falhas, como sistemas de mensagens.

Conclusão

Bom, é isso. Espero que minha explicação tenha sido clara. Caso queiram, eu posso aprofundar mais em consistência e como lidar com conflitos de escrita. Fiquem livres para adicionar o que acharem relevante!

Obrigado por lerem até aqui!

Recomendo se aprofundarem em cada um deles, dei apenas uma visão geral e superficial para compreensão geral. Alguns materiais para leitura que dão uma complementada legal:

COMO ESCALAR UM SISTEMA PARA 1 MILHÃO DE USUÁRIOS?

Stephanto — Wed, 23 Apr 2025 15:05:18 +0000

Escalar um sistema para suportar milhões de usuários é um desafio significativo. A complexidade aumenta com o aumento da carga de dados e usuários, demandando uma arquitetura robusta. Neste artigo, exploraremos como escalar um sistema para lidar com 1 milhão de usuários, utilizando boas práticas e abordagens como balanceamento de carga, caches, e sharding.

O fluxo comum de um usuário ao acessar um site é: Acessar o o site pela URL, o DNS traduzir o endereço, a requisição chegar no servidor e devolver o conteúdo para o usuário

Se começarmos a ter usuários acessando nosso site e quisermos guardar seus registros e/ou ter um backend que queremos armazenar dados, temos que ter um database que vai salvar e resgatar esses dados

Porém, como temos apenas 1 servidor, a medida que o número de usuários aumenta, pode gerar delay e timeout para alguns usuários, para isso adicionamos o loadbalancer que vai cuidar de encaminhar os usuários para os diferente servidores para não sobrecarregar

Agora, como teremos mais de um banco de dados (por conta do aumento de servidores), precisamos garantir a consistência dos dados. Podemos utilizar o método de Master/Slave, que somente 1 database recebe as escritas, replica para os outros e eles apenas leem os registros

Vamos dar uma olhada em como ficou nosso sistema até agora então, está bom mas ainda podemos melhorar bastante a performance

Podemos adicionar um cache para dados frequentemente acessados. Assim, melhora a velocidade e poupa acessos ao banco de dados pela memória cache ser mais rápida

Podemos também adicionar um CDN. Um CDN é um servidor estrategicamente localizado em um lugar que seja mais perto do cliente, funciona semelhante a um cache

Com essas adições nosso sistema esta desta forma até agora:

Ok, mas como escalamos ainda mais? Podemos mover uma parte do sistema para stateless, por exemplo, tirar o estado do usuário do servidor e adicionar em um NoSQL. No exemplo abaixo é como seria o acesso do usuário sem stateless, sua sessão e foto de perfil ficam apenas em 1 server

Já com stateless, adicionamos um shared storage para adicionar a sessão e a foto de perfil do usuário, para manter uma boa experiência de usuário (se o loadbalancer jogar ele pra outro servidor, ele não ser deslogado ou coisa do tipo)

Com essa adição, nosso sistema está ficando cada vez mais bonito e escalável

Ta bom, mas e se seu sistema quer internacionalizar? Para isso, vamos ter outro datacenter em outro país, e com isso, adicionamos um outro loadbalancer mas com algoritmo de georoute nele

Uma boa prática (algumas vezes) é desacoplar alguma função frequente que ser servidor faz para aumentar o desempenho e diminuir o overload em um macro-serviço. Exemplo, podemos fazer um sistema separado para processamento de imagens no nosso servidor usando sistema de filas. Com esse sistema de filas, caso algum servidor caia, não é perdido a requisição, além de, como dito anteriormente, diminuir o overload

Com isso, nosso sistema fica dessa forma:

Por fim, o que podemos fazer é diminuir a sobrecarga do banco de dados. As bases de dados estão apenas com redundância até agora, com os mesmos tipos de dados em todos eles. Com isso, podemos usar um método chamado sharding.
Sharding é, de forma simplifcada, usar um algoritmo para dividir a alocação de um registro em bases de dados diferentes. O exemplo abaixo vai elucidar melhor.
Vou pegar o id do usuário e fazer módulo 4, o resultado vai fazer com que ele seja salvo em um DB especifico

Essa é uma visão de como ficaria cada um dos bancos de dados após o sharding:

Agora juntando tudo isso que temos, voltamos para a imagem inicial do artigo. Vocês tem um sistema escalável para bem mais que 1 milhão de usuários!

Espero que tenham compreendido de forma simples o funcionamento disso. Novamente, aconselho aprofundar no assunto!

Obrigado por ler até aqui!