DEV Community: Freitas-Mp

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