DEV Community: Freitas-Mp

📱 Vamos aprender System Design desenhando o WhatsApp

Freitas-Mp — Wed, 23 Sep 2026 13:48:22 +0000

📱 System Design do WhatsApp

Neste artigo, mostramos como o WhatsApp pode ser desenhado passo a passo, começando pelos problemas reais do sistema e descobrindo, a partir deles, os conceitos de engenharia necessários para resolvê-los.

Uma aprendizagem adaptativa através dos problemas

👨🏾‍💻 Pedro & 🤵🏾‍♂️ João

Introdução

Esta não é uma aula tradicional de System Design.

É o registro de uma sessão real de aprendizagem na qual Pedro tentou projetar, passo a passo, um sistema semelhante ao WhatsApp.

Pedro não recebeu previamente uma lista de conceitos.

Ele recebeu problemas.

A cada problema, tentou encontrar uma solução.

Algumas hipóteses estavam corretas.

Outras estavam incompletas.

Outras estavam erradas.

E foi justamente a partir dessas respostas que João decidiu qual deveria ser a próxima pergunta.

A sequência foi:

Problema → hipótese → consequência → dúvida → correção → descoberta → conceito → novo problema.

O objetivo deste documento é preservar esse processo.

📱 Começamos pela mensagem

🤵🏾‍♂️ João: Pedro, vamos começar pelo mais simples. Temos dois usuários que querem trocar uma mensagem. Como essa mensagem sai do telefone de uma pessoa e chega ao telefone da outra?

👨🏾‍💻 Pedro: A mensagem sai pela Internet, chega ao nosso servidor e depois vai para o telefone do outro usuário.

🤵🏾‍♂️ João: Certo. Mas agora temos um problema. Se o usuário estiver constantemente recebendo mensagens, precisamos abrir uma conexão nova para cada mensagem?

👨🏾‍💻 Pedro: Não. Precisamos de uma conexão persistente.

🤵🏾‍♂️ João: E qual tecnologia poderia permitir essa comunicação contínua entre o cliente e o servidor?

👨🏾‍💻 Pedro: WebSocket.

🤵🏾‍♂️ João: Exatamente.

Aqui apareceu o primeiro conceito importante: WebSocket como canal de comunicação persistente e bidirecional.

Mas a solução imediatamente criou outro problema.

🖥️ E se tivermos vários servidores?

🤵🏾‍♂️ João: Agora imagine que temos milhares ou milhões de usuários. Um único servidor não seria suficiente. Teríamos vários servidores WebSocket. Como distribuímos as conexões?

👨🏾‍💻 Pedro: Load Balancer.

🤵🏾‍♂️ João: Sim. O Load Balancer pode distribuir as novas conexões entre os servidores.

Mas agora pensa:

Pedro está conectado ao servidor A.

Outro servidor recebe uma mensagem destinada a Pedro.

Como esse servidor sabe onde Pedro está?

👨🏾‍💻 Pedro: Talvez os servidores possam saber uns dos outros?

🤵🏾‍♂️ João: Poderiam existir mecanismos de comunicação entre eles, mas isso começa a criar um problema de estado distribuído. Se cada servidor guardar apenas na própria memória os usuários conectados, o que acontece quando outro servidor precisar dessa informação?

👨🏾‍💻 Pedro: Então precisamos de alguma informação compartilhada.

🤵🏾‍♂️ João: Exatamente.

E foi aí que começamos a chegar ao Redis.

🔴 Onde está o usuário?

🤵🏾‍♂️ João: Precisamos de alguma coisa que possa ser acessada pelos diferentes servidores. O que poderíamos utilizar?

👨🏾‍💻 Pedro: Redis.

🤵🏾‍♂️ João: Isso.

O Redis pode funcionar como uma camada de estado compartilhado.

Por exemplo:

userId → servidor/conexão atual

Agora qualquer servidor pode consultar onde está a conexão atual daquele usuário.

Mas ainda não terminamos.

⏳ E se o estado ficar velho?

🤵🏾‍♂️ João: Imagine que Pedro estava conectado ao servidor A. O Redis registra isso. Mas Pedro perde a Internet de repente.

O que acontece se o Redis continuar acreditando que Pedro está conectado ao servidor A?

👨🏾‍💻 Pedro: O estado fica errado.

🤵🏾‍♂️ João: Então como podemos descobrir que aquela conexão já não está viva?

👨🏾‍💻 Pedro: Heartbeat?

🤵🏾‍♂️ João: Sim.

E poderíamos combinar isso com um TTL para que informações antigas expirem.

Agora apareceu outro problema.

🔄 Reconexão

🤵🏾‍♂️ João: Pedro perdeu a conexão e voltou. Só que, desta vez, caiu no servidor B.

Temos agora uma conexão antiga e uma conexão nova.

Como sabemos qual é a atual?

👨🏾‍💻 Pedro: Precisamos de algum ID da conexão.

🤵🏾‍♂️ João: Exatamente.

A ideia de uma geração, versão ou identificador de conexão ajuda a diferenciar:

conexão antiga

de:

conexão atual

Isso evita que eventos atrasados da conexão antiga sejam tratados como se fossem da conexão atual.

✅ A mensagem realmente chegou?

🤵🏾‍♂️ João: Agora temos o caminho da mensagem. Mas o servidor enviou a mensagem para o dispositivo. Como sabemos que ela realmente chegou?

👨🏾‍💻 Pedro: ACK.

🤵🏾‍♂️ João: Exatamente.

Aqui começamos a distinguir uma coisa importante: o ACK é uma confirmação no nível da aplicação.

Não é simplesmente uma notificação push.

Mas agora o ACK criou outro problema.

🔁 E se o ACK desaparecer?

🤵🏾‍♂️ João: O servidor enviou a mensagem.

O dispositivo recebeu.

Mas, por algum motivo, o ACK não chegou ao servidor.

O que o servidor pode pensar?

👨🏾‍💻 Pedro: Que a mensagem não chegou.

🤵🏾‍♂️ João: E então?

👨🏾‍💻 Pedro: Ele vai tentar novamente.

🤵🏾‍♂️ João: E o que pode acontecer?

👨🏾‍💻 Pedro: A mensagem pode ser enviada duas vezes.

🤵🏾‍♂️ João: Exatamente.

Agora precisamos de uma maneira de reconhecer que aquela segunda tentativa representa a mesma mensagem.

👨🏾‍💻 Pedro: Message ID.

🤵🏾‍♂️ João: Isso.

E aqui aparece outro conceito:

idempotência.

Se uma mesma operação for repetida, ela não deve produzir um efeito incorretamente duplicado.

🖼️ Agora temos uma imagem de 8 MB

🤵🏾‍♂️ João: Até aqui falamos principalmente de texto.

Agora Pedro quer enviar uma imagem de 8 MB.

Vamos mandar esses 8 MB diretamente pelo WebSocket?

👨🏾‍💻 Pedro: Não parece uma boa ideia.

🤵🏾‍♂️ João: Então onde podemos armazenar o arquivo?

👨🏾‍💻 Pedro: Object Storage.

🤵🏾‍♂️ João: E se quisermos distribuir esse arquivo de forma eficiente?

👨🏾‍💻 Pedro: CDN.

🤵🏾‍♂️ João: Exatamente.

Começamos então a separar as responsabilidades:

Mensagem
↓
mediaId
↓
Object Storage
↓
CDN

O WebSocket transporta a informação da mensagem, enquanto o arquivo físico fica em uma infraestrutura própria para armazenamento e distribuição de mídia.

🔢 “Mas já temos um ID. Para quê o hash?”

🤵🏾‍♂️ João: Agora surge outra questão. Podemos utilizar um hash da imagem para identificar o conteúdo.

👨🏾‍💻 Pedro: Agora aqui fica um pouquinho estranho, visto que já temos um ID. Por que é que precisamos mais do hash? Talvez pudéssemos usar um ID.

🤵🏾‍♂️ João: Essa dúvida é importante.

O "mediaId" identifica a entidade lógica.

O hash tem outra função: representar o conteúdo.

Se dois arquivos tiverem exatamente o mesmo conteúdo, podemos calcular o mesmo hash para eles.

Então surge um novo problema.

♻️ A mesma imagem novamente

🤵🏾‍♂️ João: Imagine que Pedro envia uma imagem para uma pessoa.

Depois envia exatamente a mesma imagem para outra.

Precisamos armazenar fisicamente duas cópias?

👨🏾‍💻 Pedro: Mas a cada upload é um novo hash, não?

🤵🏾‍♂️ João: Não necessariamente. O hash depende do conteúdo. Se o conteúdo for exatamente igual, o hash calculado também pode ser igual.

👨🏾‍💻 Pedro: Ah, eu acho que, então, aí entra o conceito de deduplicação, onde evitamos que a mesma imagem seja repetida no nosso servidor, no CDN ou no storage, certo? Então eu acho que aqui a ideia de usar deduplicação é muito interessante.

🤵🏾‍♂️ João: Exatamente.

Aqui o hash deixou de parecer apenas “mais um ID”.

Ele passou a ter uma função concreta:

reconhecer conteúdo equivalente e permitir deduplicação.

Também pode ser utilizado posteriormente para verificar a integridade do arquivo.

🗑️ Podemos apagar a imagem?

🤵🏾‍♂️ João: Agora temos uma imagem armazenada.

Imagine que uma mensagem seja apagada.

Podemos simplesmente apagar o arquivo físico?

👨🏾‍💻 Pedro: Não, porque talvez outras mensagens ainda estejam usando a mesma imagem.

👨🏾‍💻 Pedro: Claro, a massa física não pode ser eliminada, porque ainda está sendo referenciada pelo M2 e M3.

🤵🏾‍♂️ João: Exatamente.

O arquivo físico possui várias referências.

Então precisamos saber quantas referências ainda existem.

Surge:

reference_count

Quando uma mensagem deixa de referenciar a mídia, o contador pode ser reduzido.

Mas isso trouxe outro problema.

⚔️ Duas operações ao mesmo tempo

🤵🏾‍♂️ João: Imagine duas requisições tentando remover uma referência exatamente ao mesmo tempo.

O que pode acontecer?

👨🏾‍💻 Pedro: Esse conceito de deadlock, né?

🤵🏾‍♂️ João: Pode haver deadlock em determinados cenários de concorrência, mas aqui precisamos olhar primeiro para outro problema.

Duas operações estão tentando alterar o mesmo estado simultaneamente.

👨🏾‍💻 Pedro: Assim, race condition, exatamente. Concorrência de quem vai pegar primeiro.

🤵🏾‍♂️ João: Isso.

O problema principal aqui é race condition.

Agora vamos pensar na operação:

UPDATE media
SET reference_count = reference_count - 1
WHERE media_id = 'IMG900'
AND reference_count > 0;

🧮 “Mas os dois podem tentar fazer a mesma coisa?”

👨🏾‍💻 Pedro:

UPDATE media
SET reference_count = reference_count - 1
WHERE media_id = 'IMG900'
AND reference_count > 0;

Mas é o mesmo problema do if else. Os dois vão tentar acessar a mesma coisa de uma vez?

🤵🏾‍♂️ João: A preocupação é exatamente sobre concorrência.

A diferença é que o banco possui mecanismos para coordenar operações concorrentes sobre a mesma linha.

Uma operação atômica desse tipo permite que o próprio MySQL faça a alteração de maneira segura, evitando o clássico problema de duas operações lerem o mesmo valor e depois sobrescreverem o resultado uma da outra.

👨🏾‍💻 Pedro: Essa pergunta é interessante porque, mesmo depois de resolver a concorrência, ainda pode haver outro problema, não pode? Não é que ele não possa acessar, mas a questão que analisamos naquela hora já tem aí uma condição: se for maior que zero. Então, nesse caso, essa condição vai impedir isso.

🤵🏾‍♂️ João: Exatamente.

A condição:

reference_count > 0

também impede que o contador seja decrementado abaixo de zero.

🗄️ MySQL ou Object Storage?

👨🏾‍💻 Pedro: Então, essa concorrência vai ser resolvida no MySQL, no banco, certo? Não no Object Storage. O banco só vai coordenar junto com o Object Storage.

🤵🏾‍♂️ João: Exatamente.

Essa distinção é muito importante.

O MySQL controla:

estado;
metadados;
referências;
contadores;
decisões sobre o ciclo de vida.

O Object Storage mantém:

o arquivo físico.

Eles são sistemas diferentes.

Não podemos assumir que uma operação no MySQL e outra no Object Storage fazem parte automaticamente de uma única transação ACID.

E isso cria mais um problema.

🔄 O Object Storage falhou

🤵🏾‍♂️ João: O MySQL indica que o objeto deve ser removido.

Mas justamente nesse momento o Object Storage está indisponível.

O que fazemos?

👨🏾‍💻 Pedro: Aqui entramos na questão do retry, certo? Vamos tentar novamente.

🤵🏾‍♂️ João: Exatamente.

Mas agora o retry cria uma nova pergunta:

«E se a primeira operação tiver sido executada, mas a resposta tiver desaparecido?»

Se simplesmente repetirmos tudo, podemos executar uma operação duas vezes.

Voltamos então à:

idempotência.

🌊 “Ah, lembrei do streaming”

🤵🏾‍♂️ João: Agora vamos pensar em arquivos grandes.

Precisamos necessariamente enviar todo o arquivo como uma única transferência?

👨🏾‍💻 Pedro: Ah, lembrei do streaming, né?

🤵🏾‍♂️ João: Sim.

Streaming permite processar ou transferir dados progressivamente.

Mas vamos complicar.

Imagine um arquivo de 100 MB.

Pedro já enviou 50 MB.

A conexão cai.

O que fazemos?

📍 “Aqui entra checkpoint?”

👨🏾‍💻 Pedro: Ah, interessante. Não. Acho que aqui devemos começar de onde paramos. Aqui entra, acho, o conceito de checkpoint, certo?

🤵🏾‍♂️ João: Exatamente.

Não queremos necessariamente começar o upload novamente do zero.

Precisamos saber até onde chegamos.

O checkpoint permite registrar o progresso e continuar posteriormente.

Isso nos leva ao conceito de resumable upload.

📦 E se o chunk for enviado duas vezes?

🤵🏾‍♂️ João: Agora imagine que o arquivo foi dividido em chunks.

O cliente envia um chunk.

O servidor recebe.

Mas o ACK desse chunk não chega ao cliente.

O que o cliente pode fazer?

👨🏾‍💻 Pedro: Ele vai tentar novamente.

🤵🏾‍♂️ João: E agora temos novamente o problema de duplicação.

👨🏾‍💻 Pedro: Realmente, aí sim, ele vai tentar duplicar de novo e aí temos que ter a idempotência, né, para evitar que os arquivos sejam duplicados quando já existe.

🤵🏾‍♂️ João: Exatamente.

Precisamos identificar cada chunk dentro daquele upload.

Por exemplo:

uploadId + chunkNumber

Assim podemos reconhecer uma tentativa repetida.

Mais uma vez:

retry → possibilidade de repetição → idempotência.

✅ ACK não é o mesmo que COMPLETED

👨🏾‍💻 Pedro: Bom, então aqui também o conceito de ACK pode ajudar, certo? Marcar como concluído.

🤵🏾‍♂️ João: Sim, se estamos falando do ACK, ele pode confirmar que uma determinada parte foi recebida.

Mas precisamos separar duas coisas.

Um ACK pode significar:

“Recebi este chunk.”

Enquanto:

COMPLETED

pode significar:

“O upload inteiro terminou.”

São estados diferentes.

👨🏾‍💻 Pedro: Como assim? Como é que isso se enquadra aí?

🤵🏾‍♂️ João: Porque precisamos distinguir a confirmação de uma parte da confirmação do processo inteiro.

Se temos 20 chunks:

Chunk 1 → ACK
Chunk 2 → ACK
Chunk 3 → ACK
...
Chunk 20 → ACK

isso não significa necessariamente que o processo inteiro já foi finalizado.

O estado global pode ser atualizado para:

COMPLETED

somente quando todas as partes necessárias tiverem sido recebidas e o arquivo tiver sido reconstruído e validado.

E, nesse momento, o hash pode voltar a ser útil para verificar a integridade do arquivo final.

🧠 O que aconteceu durante a aprendizagem?

👨🏾‍💻 Pedro: Muito bom. Então vamos parar por aqui, né? Foi bom.

🤵🏾‍♂️ João: Foi.

Mas o mais interessante desta sessão não foi a quantidade de conceitos que apareceram.

Foi a forma como eles apareceram.

Pedro não começou dizendo:

«“Vamos estudar WebSocket.”»

Ele começou tentando responder:

«“Como uma mensagem chega ao outro usuário?”»

Quando apareceu outro problema, surgiu outro conceito.

Quando uma hipótese não explicava completamente o comportamento do sistema, apareceu uma nova pergunta.

Quando Pedro confundiu deadlock com race condition, a diferença tornou-se necessária.

Quando o hash pareceu apenas mais um identificador, surgiu o problema da deduplicação.

Quando duas operações puderam acontecer simultaneamente, surgiu a necessidade de entender concorrência.

Quando MySQL e Object Storage passaram a depender um do outro, surgiu retry.

Quando retry passou a poder repetir operações, surgiu idempotência novamente.

Quando um upload podia cair no meio, surgiu checkpoint.

Quando o ACK de um chunk podia desaparecer, a idempotência apareceu novamente em outro contexto.

Ou seja:

um conceito não foi estudado isoladamente.

Ele foi reutilizado quando um novo problema apareceu.

🔄 O padrão da nossa aprendizagem

O que aconteceu durante a sessão pode ser representado assim:

PROBLEMA
↓
PEDRO TENTA RESOLVER
↓
HIPÓTESE
↓
JOÃO QUESTIONA
↓
NOVA CONSEQUÊNCIA
↓
ERRO OU DESCOBERTA
↓
CONCEITO
↓
SOLUÇÃO
↓
NOVO PROBLEMA
↓
...

E isso é importante porque Pedro não acertou tudo.

Houve momentos em que:

a hipótese precisava ser corrigida;
um conceito foi confundido com outro;
uma solução parecia suficiente, mas gerou outro problema;
uma pergunta precisou ser reformulada;
uma consequência só ficou clara depois da intervenção de João.

Esses momentos não devem ser removidos.

Eles são parte do aprendizado.

🎯 O verdadeiro objetivo

O objetivo desta abordagem não é fazer Pedro parecer um especialista.

É mostrar Pedro se tornando capaz de raciocinar como um engenheiro de sistemas.

Um engenheiro não recebe todos os problemas antecipadamente.

Ele encontra problemas.

Formula hipóteses.

Testa essas hipóteses.

Descobre limitações.

Analisa consequências.

Escolhe mecanismos.

E depois descobre que a solução de um problema pode criar outro problema.

É exatamente isso que aconteceu nesta sessão.

🧠 Adaptive Inquiry — Aprendizagem Guiada e Adaptativa

A sessão segue o princípio:

«O problema cria a necessidade de aprender o conceito.»

Em vez de:

Hoje vamos estudar:

WebSocket
Redis
ACK
Idempotência
CDN
Race Condition
Checkpoint

fazemos:

Como entregar a mensagem?
↓
Precisamos de conexão persistente.
↓
WebSocket.

Como localizar o usuário?
↓
Precisamos de estado compartilhado.
↓
Redis.

Como saber que chegou?
↓
ACK.

E se o ACK desaparecer?
↓
Retry.

E se o retry duplicar?
↓
Idempotência.

E se for uma imagem?
↓
Object Storage + CDN.

E se a imagem for repetida?
↓
Hash + deduplicação.

E se duas referências forem removidas simultaneamente?
↓
Race Condition.

Como coordenar?
↓
MySQL / atomicidade.

E se o storage falhar?
↓
Retry.

E se o upload cair no meio?
↓
Checkpoint.

E se um chunk for reenviado?
↓
Idempotência novamente.

O conhecimento vai sendo construído conforme o sistema apresenta novas dificuldades.

🏁 Conclusão

Esta sessão não foi apenas sobre desenhar um sistema semelhante ao WhatsApp.

Foi uma demonstração de como aprender System Design através dos próprios problemas do sistema.

Pedro errou.

Pedro fez suposições.

Pedro confundiu conceitos.

Pedro voltou atrás.

Pedro percebeu algumas coisas sozinho.

João corrigiu outras.

E, principalmente, cada resposta de Pedro serviu como informação para decidir qual deveria ser a próxima pergunta.

Essa é a essência do Adaptive Inquiry:

«Não ensinar primeiro o conceito para depois procurar um problema.

Apresentar o problema e permitir que a necessidade revele o conceito.»

Assim, o objetivo não é memorizar:

“Redis serve para X.”

É chegar a um ponto em que Pedro pensa:

«“Temos vários servidores e eles precisam compartilhar o estado da conexão. Então precisamos de alguma coisa compartilhada.”»

E então o Redis deixa de ser uma palavra decorada.

Ele passa a ser uma resposta para um problema que Pedro já entendeu.

Da mesma forma, idempotência deixa de ser uma definição.

Ela nasce quando Pedro percebe:

«“Se eu tentar novamente, posso duplicar a operação.”»

E checkpoint deixa de ser apenas um termo.

Ele aparece quando Pedro percebe:

«“Não faz sentido começar novamente de onde já chegamos.”»

Esse é o tipo de aprendizagem que queremos construir:

problema → raciocínio → erro → evidência → descoberta → conceito → aplicação → novo problema.

E é justamente isso que significa aprender System Design através do raciocínio, e não apenas através da memorização de conceitos.

Race Condition Lock

Freitas-Mp — Mon, 21 Sep 2026 22:39:53 +0000

🧠 Consulta Guiada e Adaptativa

Uma conversa entre Matondo Pedro e João

Tema: Race Condition → Lock

👨‍🏫 João:

Vamos começar com um problema real.

Imagina uma loja que tem apenas uma unidade de determinado produto.

O João e a Maria entram na loja exatamente ao mesmo tempo e os dois tentam comprar esse produto.

O que achas que pode acontecer?

👨‍💻 Matondo Pedro:

Os dois podem tentar comprar o mesmo produto e isso pode gerar um erro.

👨‍🏫 João:

Exatamente. Mas vamos olhar com mais cuidado.

Imagina que o stock é:

stock = 1

O João consulta:

stock > 0 → sim

Ao mesmo tempo, a Maria também consulta:

stock > 0 → sim

Os dois recebem uma resposta válida.

O que pode acontecer depois?

👨‍💻 Matondo Pedro:

Talvez a Maria fique com "-1"?

👨‍🏫 João:

Não necessariamente.

O problema mais perigoso é que os dois podem confirmar a compra, mesmo existindo apenas uma unidade física do produto.

Cada operação, isoladamente, parecia válida.

O problema surgiu porque elas aconteceram ao mesmo tempo sobre o mesmo estado compartilhado.

É uma Race Condition.

👨‍💻 Matondo Pedro:

É como se os dados fossem replicados para os dois utilizadores.

👨‍🏫 João:

A ideia está próxima, mas pensa de outra forma.

Imagina uma sala com apenas uma porta.

Duas pessoas chegam ao mesmo tempo.

As duas perguntam:

«“A sala está livre?”»

As duas recebem:

«“Sim.”»

Antes que uma delas entre, a outra também entra.

O problema não é que a sala foi “replicada”.

O problema é que duas pessoas observaram o mesmo estado antes de qualquer uma conseguir alterá-lo.

👨‍💻 Matondo Pedro:

Então o "if (stock > 0)" não resolve?

👨‍🏫 João:

Exatamente.

Porque podemos ter:

João: if (stock > 0) → SIM
Maria: if (stock > 0) → SIM

Os dois passaram pela condição.

Então, como poderíamos impedir que duas operações conflitantes trabalhassem simultaneamente sobre o mesmo recurso?

👨‍💻 Matondo Pedro:

Poderíamos colocar numa fila.

👨‍🏫 João:

Sim. Uma fila poderia serializar as operações.

Mas imagina uma loja com 10.000 clientes.

Seria necessário colocar todos numa única fila?

👨‍💻 Matondo Pedro:

Não. Só os que estão tentando comprar o mesmo produto.

👨‍🏫 João:

Exatamente.

Então precisamos de uma forma de controlar o acesso ao recurso que está em conflito, e não bloquear o sistema inteiro.

O que poderíamos usar para isso?

👨‍💻 Matondo Pedro:

Um lock.

Como colocar um cadeado no produto.

👨‍🏫 João:

Perfeito. 🔒

E onde faria sentido esse lock existir?

👨‍💻 Matondo Pedro:

No banco de dados.

👨‍🏫 João:

Exatamente.

Por exemplo:

SELECT *
FROM products
WHERE id = 1
FOR UPDATE;

Esse "FOR UPDATE" permite bloquear a linha que estamos prestes a modificar.

Assim, outra transação que precise de um lock incompatível nessa mesma linha terá de esperar.

E agora aparece uma nova pergunta:

O lock sozinho é suficiente para representar toda a compra?

🎯 O método

Nesta conversa, não começámos pela definição de Race Condition ou Lock.

Começámos por um problema real, fizemos perguntas, testámos hipóteses e fomos descobrindo os conceitos à medida que eles se tornavam necessários.

🧠 Consulta Guiada e Adaptativa: começar pelo problema e conduzir a pessoa até à descoberta da solução.

Aprendendo Angular através de um diálogo

Freitas-Mp — Mon, 21 Sep 2026 22:32:05 +0000

🧠 INVESTIGAÇÃO ADAPTATIVA

Dia 1 — Aprendendo Angular através de um diálogo

👨‍💼 João — Entrevistador

Olá, eu sou o João. Trabalho na empresa X e hoje vou conduzir uma entrevista técnica para uma vaga de Junior Frontend Developer.

Vamos começar com uma situação real.

Precisamos desenvolver uma aplicação para uma escola.

A aplicação deve permitir fazer login, listar estudantes, cadastrar, editar e remover estudantes. Os dados vêm de uma API REST.

Acabaste de criar o projeto Angular.

Como começarias a organizar essa aplicação?

👨‍💻 Matando Pedro — Candidato

Certo. Então a primeira coisa que eu vou fazer é criar a estrutura do projeto.

Vou instalar o Angular com npm, instalar a versão mais recente e o Angular já começa a definir toda a base do projeto, com services, components, HTML e toda essa estrutura inicial.

Depois vou fazer uma tela de login e cadastro.

Também vou criar a parte da API de estudantes.

Depois vou criar uma tela para listar os estudantes, um componente.

Outra tela para mostrar os detalhes do estudante.

E na lista vou colocar uma opção para eliminar o estudante.

Depois vou usar um Service para fazer...

👨‍💼 João

O que exatamente colocarias dentro desse Service?

Imagina que tens um "StudentListComponent" e precisas buscar os estudantes através de:

"GET /api/students"

Quem deveria fazer essa chamada HTTP: o componente ou o Service? E por quê?

👨‍💻 Matando Pedro

O Service.

Porque normalmente Service é algo compartilhado pela aplicação.

A chamada HTTP pode ser reutilizada em diferentes partes. Se eu colocasse no componente, teria que replicar esse código sempre que criasse outro componente.

👨‍💼 João

A ideia principal está correta.

Mas vamos refinar.

A razão principal não é simplesmente o Service ser compartilhado.

É separação de responsabilidades.

O componente deve preocupar-se principalmente com a interface e interação.

O Service pode encapsular a responsabilidade de obter e manipular os estudantes.

Então temos:

Component → Service → HttpClient → API

👨‍💼 João

Agora outra pergunta.

O Service deve conter toda a lógica da aplicação?

👨‍💻 Matando Pedro

Não necessariamente.

No Service podemos implementar helpers, providers HTTP e lógica de negócio.

Ele é muito bom para comunicação externa.

👨‍💼 João

Boa. Só precisamos fazer uma precisão.

Service não significa simplesmente “comunicação externa”.

Ele serve para encapsular uma responsabilidade que não deveria ficar diretamente no componente.

Comunicação com API é apenas um dos usos.

Agora temos outro problema.

A rota "/students" só pode ser acessada por usuários autenticados.

O que usarias?

👨‍💻 Matando Pedro

Usaria o recurso do Angular chamado Guard.

Ele vai proteger a rota e verificar se o acesso está autorizado.

👨‍💼 João

Exatamente.

Guard.

Agora aparece outro problema.

Todas as requisições precisam enviar o token:

"Authorization: Bearer "

Temos:

"GET /students"
"POST /students"
"PUT /students/1"
"DELETE /students/1"

Você colocaria o código do token dentro de cada método do Service?

👨‍💻 Matando Pedro

Não.

Criaria um... um base... alguma coisa que faça esse token.

👨‍💼 João

A ideia de centralizar está correta.

O recurso que procuramos é o HTTP Interceptor.

Ele pode interceptar as requisições HTTP e adicionar automaticamente o token.

Então agora temos:

Component
↓
Service
↓
HttpClient
↓
Interceptor
↓
API

👨‍💼 João

A API devolve:

"2005-03-15"

Mas queremos mostrar na tela:

"15/03/2005"

Você colocaria essa transformação dentro do Service?

👨‍💻 Matando Pedro

Aqui não me vem à mente...

Talvez usem Terraform?

👨‍💼 João

Boa. Não acertaste, e isso é exatamente o que queremos descobrir durante o estudo.

Aqui o recurso é o Pipe.

O Pipe é usado para transformar um valor na apresentação.

Por exemplo:

"{{ student.birthDate | date:'dd/MM/yyyy' }}"

Resultado:

15/03/2005

Então:

Service → responsabilidade e acesso aos dados.
Pipe → transformação para apresentação.
Component → interface e interação.

👨‍💼 João

Agora temos outro problema.

Na tela queremos mostrar:

João — Ativo
Maria — Inativo
Pedro — Ativo

Queremos aplicar uma classe CSS diferente dependendo do estado.

Ativo → verde.
Inativo → cinza.

Que recurso do Angular utilizarias?

👨‍💻 Matando Pedro

Podemos usar a directive "ngModel".

Ela permite colocar condições dentro do HTML para definir cores.

👨‍💼 João

Estás perto no conceito de Directive, mas confundiste dois recursos.

"ngModel" é usado principalmente para two-way data binding, especialmente em formulários.

Para alterar a aparência, podemos utilizar, por exemplo:

"[class.active]="student.active""

ou "ngClass".

Então aprendemos mais uma coisa:

Directive permite adicionar ou modificar comportamento de elementos no DOM.

E "ngModel" é uma directive relacionada principalmente ao binding de formulários.

👨‍💼 João

O projeto cresceu.

Temos:

"students/"
→ "student-list"
→ "student-detail"
→ "student-form"

"auth/"
→ "login"
→ "register"

Como organizarias e agruparias esses componentes no Angular?

E qual é a diferença entre NgModule e Standalone?

👨‍💻 Matando Pedro

Entre módulos, nós organizamos os componentes por módulos e depois vamos ter um módulo pai que vai chamar os children.

E carrega as rotas.

Isso facilita na eficiência de lazy loading e tudo isso.

Standalone, acho que é quando temos um único módulo pai que carrega todos os ficheiros.

👨‍💼 João

A primeira parte está no caminho certo.

No modelo tradicional, podemos agrupar funcionalidades através de "NgModule".

Por exemplo:

"StudentsModule"
→ "StudentListComponent"
→ "StudentDetailComponent"
→ "StudentFormComponent"

Mas há uma correção importante.

Standalone é praticamente o contrário daquilo que descreveste.

Um componente Standalone pode declarar diretamente as suas dependências sem precisar pertencer a um "NgModule".

👨‍💼 João

Você mencionou lazy loading.

Por que utilizaria lazy loading?

Temos:

"/"
"/login"
"/students"
"/reports"
"/admin"

Por que não simplesmente carregar tudo quando a aplicação começa?

👨‍💻 Matando Pedro

Porque à medida que o projeto vai crescer, vai ficar muito lento o Angular fazer um build e descarregar todo o projeto.

Isso pode matar a eficiência da aplicação.

👨‍💼 João

O raciocínio está correto.

Só precisamos fazer uma precisão.

O problema principal para o usuário não é o build ficar lento. O build acontece durante desenvolvimento ou CI.

O problema é o carregamento inicial da aplicação.

Sem lazy loading, o usuário pode acabar carregando recursos que ainda nem precisa.

Com lazy loading, partes da aplicação podem ser carregadas quando forem necessárias.

🧠 O que aconteceu nesta entrevista?

Nós não começámos decorando definições.

Começámos com um problema.

Uma resposta gerou uma nova pergunta.

A pergunta revelou uma lacuna.

A lacuna levou à investigação.

A investigação revelou o conceito.

E o conceito foi colocado diante de outro problema.

Problema → Hipótese → Pergunta → Investigação → Conceito → Aplicação → Transferência

Essa é a ideia por trás da Investigação Adaptativa.

«Aprender não precisa começar pela definição.

Às vezes, começa por uma pergunta que revela aquilo que ainda não sabemos.»

Capítulo 21 — Deadlock: Quando o Sistema Fica Esperando por Ele Mesmo

Freitas-Mp — Mon, 21 Sep 2026 22:27:17 +0000

Capítulo 21 — Deadlock: Quando o Sistema Fica Esperando por Ele Mesmo

Uma falha que nos obrigou a parar tudo

Estávamos construindo o sistema.

Tudo parecia funcionar.

Até que, durante um teste de concorrência, colocamos cinco execuções fazendo a mesma operação praticamente ao mesmo tempo.

E então apareceu:

ER_LOCK_DEADLOCK

A princípio, parece apenas mais um erro técnico.

Mas a pergunta é muito mais interessante:

«O que significa, de verdade, um sistema entrar em deadlock?»

Foi assim que começou a nossa investigação.

🧑‍💻 Matondo Pedro

João, afinal, o que aconteceu aqui?

👨‍💻 João

Antes de falar de banco de dados, vamos esquecer programação por um momento.

Imagina duas pessoas organizando documentos.

👨 A está segurando um documento que B precisa.

👩 B está segurando outro documento que A precisa.

Então:

👨 A → espera B
👩 B → espera A

Quem continua?

🧑‍💻 Matondo Pedro

Ninguém.

A está esperando B.

B está esperando A.

Então fica tudo travado.

👨‍💻 João

Exatamente.

Agora temos uma descoberta.

Não é simplesmente esperar que causa o problema.

Se B estivesse esperando A, mas A pudesse terminar sozinho:

👩 B → espera 👨 A

👨 A → termina
↓
👩 B → continua

Tudo ficaria bem.

O problema aparece quando a espera volta para o início.

👨 A → espera 👩 B
↑ ↓
└───────┘

Temos um círculo.

🧑‍💻 Matondo Pedro

Então, se tivermos cinco pessoas, pode ficar ainda pior?

👨‍💻 João

Pode.

Imagina:

👨 A espera 👩 B
👩 B espera 👨 C
👨 C espera 👩 D
👩 D espera 👨 E
👨 E espera 👩 A

Agora ninguém consegue avançar.

E olha uma coisa interessante:

nenhuma pessoa necessariamente fez algo errado.

Cada uma simplesmente está esperando outra pessoa.

O problema só aparece quando olhamos para o conjunto inteiro.

Voltando para o nosso sistema

👨‍💻 João

Agora vamos voltar para o S04.

Tínhamos cinco execuções acontecendo simultaneamente:

Execução A ─┐
Execução B ─┤
Execução C ─┼──→ mesma interactionId
Execução D ─┤
Execução E ─┘

O cursor daquela interação ainda não existia.

Então todas chegaram praticamente à mesma conclusão:

«"Não existe cursor. Preciso criá-lo."»

E todas tentaram fazer isso.

Foi aí que apareceu o nosso:

ER_LOCK_DEADLOCK

🧑‍💻 Matondo Pedro

Ah! Então o problema que encontramos no nosso projeto é o mesmo padrão.

👨‍💻 João

Exatamente.

Mas com uma precisão importante:

não significa que o banco de dados inteiro parou.

Algumas operações ficaram envolvidas numa dependência circular.

O banco detectou a situação e escolheu uma ou mais transações como vítimas, desfazendo aquela operação para permitir que o sistema continuasse.

🧑‍💻 Matondo Pedro

Então o banco precisa "matar" alguns processos?

👨‍💻 João

De forma simplificada, podemos dizer isso.

Tecnicamente, ele pode abortar uma transação e fazer rollback.

E isso produz uma descoberta interessante:

«Às vezes, o erro é justamente o mecanismo que impede o sistema de ficar bloqueado para sempre.»

Mas isso só acontece em bancos de dados?

🧑‍💻 Matondo Pedro

Essa é uma coisa que fiquei curioso.

Deadlock só acontece em banco de dados?

👨‍💻 João

Não.

O banco é apenas um dos lugares onde esse problema aparece.

O padrão é muito mais amplo.

Pode acontecer quando:

👥 pessoas esperam umas pelas outras;
🏭 máquinas dependem umas das outras;
🚗 veículos ficam presos em uma passagem;
💻 programas aguardam recursos;
🗄️ transações aguardam recursos do banco.

A estrutura é sempre parecida:

A possui X
A precisa de Y

B possui Y
B precisa de X

E então:

A → espera B
↑ ↓
└───────┘

🧑‍💻 Matondo Pedro

Então, quando estamos projetando um sistema, precisamos levantar essas situações e tentar prever esses problemas?

👨‍💻 João

Sim.

Não conseguimos prever todos os problemas antes de construir um sistema.

Mas podemos investigar:

O que é compartilhado?

Quem pode utilizar?

Quem pode precisar esperar?

Enquanto espera, o que continua segurando?

Existe possibilidade de formar um ciclo?

Essa análise pode revelar riscos de concorrência antes que eles apareçam em produção.

Uma pequena experiência

👨‍💻 João

Agora olha para duas situações.

Primeira:

👨 A → X → Y
👩 B → Y → X

Existe possibilidade de formar um ciclo.

Agora mudamos a ordem:

👨 A → X → Y
👩 B → X → Y

O que acontece?

🧑‍💻 Matondo Pedro

Aí não temos círculo.

B pode esperar A.

Mas A não está esperando B.

Quando A terminar, B continua.

Então não temos deadlock.

👨‍💻 João

Exatamente.

Acabaste de descobrir uma das estratégias fundamentais para reduzir deadlocks:

«estabelecer uma ordem consistente para adquirir recursos.»

E se o banco não detectasse?

🧑‍💻 Matondo Pedro

Mas o que aconteceria se o banco nunca detectasse aquele deadlock?

👨‍💻 João

Imagina:

A ⏳
B ⏳

Se nenhuma pudesse sair da situação, poderiam ficar esperando indefinidamente.

E outras operações poderiam começar a esperar também:

A ⏳
B ⏳
C ⏳
D ⏳
E ⏳
...

Isso poderia consumir conexões e outros recursos, aumentar os tempos de resposta, provocar timeouts e degradar o sistema.

O sistema estaria gastando recursos sem produzir progresso útil.

🧑‍💻 Matondo Pedro

Agora lembrei de uma coisa!

Na 42 Luanda estudamos um problema chamado Dining Philosophers — O Jantar dos Filósofos.

👨‍💻 João

E agora a conexão fica muito interessante.

Nós não começamos pelos filósofos.

Encontramos o problema primeiro no nosso sistema.

Depois percebemos que existia um problema clássico que representa exatamente essa classe de situação.

🍝 Dining Philosophers Nosso sistema

🧑 Filósofo Execução
🍴 Garfo Recurso
⏳ Espera Espera
🔄 Ciclo Dependência circular
🔒 Bloqueio Deadlock

E essa é talvez a parte mais interessante da investigação.

Não estudamos deadlock porque alguém começou dizendo:

«"Deadlock é X."»

Nós começamos com:

«"Por que o nosso sistema travou?"»

Investigamos.

Fizemos perguntas.

Criamos hipóteses.

Simplificamos o problema.

Encontramos o padrão.

E só depois demos nome ao que havíamos descoberto:

«Deadlock.»

Esse é o espírito do Adaptive Inquiry: começar pelo problema real, investigar através de perguntas, descobrir o conceito e só então aprender o termo técnico.

A teoria veio depois da necessidade de entendê-la.

Coming soon !

Freitas-Mp — Sun, 21 Nov 2021 16:21:27 +0000

I will develop this application ,coming soon.
Using Nodejs,DDD,TDD and react js