Concorrência Otimista e Pessimista em APIs Node.js e PostgreSQL

O Desafio da Concorrência em Sistemas de Alta Carga

Quando milhares de usuários tentam atualizar o mesmo registro em uma API ao mesmo tempo, sistemas web comuns entram em colapso se não houver um controle rígido de concorrência. Na prática, isso significa que dois clientes podem ler o saldo de uma conta bancária ou o estoque de um produto simultaneamente, alterando o valor com base em informações que já se tornaram obsoletas segundos depois. Esse fenômeno gera condições de corrida, corrupção de dados e prejuízos financeiros severos para aplicações corporativas.

Para resolver esse problema no ecossistema backend moderno, desenvolvedores combinam a flexibilidade assíncrona do Node.js com a robustez transacional do PostgreSQL. No entanto, o design de arquiteturas resilientes exige escolhas arquiteturais profundas sobre como gerenciar o acesso simultâneo aos dados. A decisão central gira em torno de duas filosofias opostas de engenharia de software: assumir que os conflitos vão acontecer o tempo todo ou apostar que eles são raros e fáceis de corrigir depois.

Bloqueios Pessimistas com SELECT FOR UPDATE

O bloqueio pessimista parte do princípio de que os conflitos são inevitáveis e altamente prováveis em sistemas de alto tráfego. Quando uma aplicação Node.js precisa garantir que nenhum outro processo mexa em um dado crítico, ela executa uma consulta SQL utilizando a cláusula SELECT ... FOR UPDATE. Na prática, essa instrução diz ao PostgreSQL para trancar fisicamente aquelas linhas específicas na tabela até que a transação atual seja totalmente finalizada com um comando de confirmação ou cancelamento.

Implementar essa abordagem em frameworks populares ou utilizando o driver nativo exige cuidado redobrado com o tempo de espera das requisições. Se uma transação demora muito para liberar o bloqueio, as demais requisições na fila começam a acumular, disparando o tempo de resposta da API e sobrecarregando o pool de conexões do banco. Abaixo, veja um exemplo prático utilizando o ecossistema Node.js com Prisma:

async function atualizarEstoquePessimista(productId, quantidadeDesejada) {return await prisma.$transaction(async (tx) => {const [produto] = await tx.$queryRawUnsafe(`SELECT id, estoque FROM produtos WHERE id = $1 FOR UPDATE`, productId);if (produto.estoque < quantidadeDesejada) {throw new Error('Estoque insuficiente');}await tx.produto.update({where: { id: productId },data: { estoque: produto.estoque - quantidadeDesejada }});return { success: true };});}

Controle Otimista de Concorrência (OCC)

O controle otimista de concorrência adota a postura oposta: ele assume que múltiplos usuários dificilmente vão alterar o mesmo registro exatamente ao mesmo tempo. Em vez de travar o banco de dados preventivamente — o que prejudica a performance —, o sistema permite que a leitura e o processamento ocorram livremente. O momento da verdade acontece apenas no instante da gravação, onde o banco verifica se o dado foi modificado por terceiros desde a última leitura.

Para fazer isso funcionar na prática, as tabelas ganham uma coluna extra de controle, geralmente chamada de version (versão) ou um carimbo de data/hora (updated_at). Quando a API tenta atualizar o registro, ela envia a versão que leu originalmente; se o banco encontrar uma versão diferente no momento do UPDATE, significa que houve concorrência, a alteração é rejeitada e a aplicação precisa reagir. Veja como estruturar essa lógica em Node.js:

async function atualizarSaldoOtimista(userId, valorAdicional, versaoAtual) {const resultado = await prisma.usuario.updateMany({where: {id: userId,version: versaoAtual},data: {saldo: { increment: valorAdicional },version: { increment: 1 }}});if (resultado.count === 0) {throw new Error('Conflito de concorrência detectado. O registro foi modificado por outro processo.');}return { success: true };}

Mitigando Deadlocks em Sistemas Transacionais

Um deadlock, ou impasse, acontece quando duas transações concorrentes travam recursos cruzados e ficam eternamente esperando uma pela outra liberar o acesso. A transação A bloqueia o registro 1 e quer o registro 2, enquanto a transação B bloqueia o registro 2 e quer o registro 1. O PostgreSQL detecta essa situação após alguns segundos e interrompe forçadamente uma das transações, gerando um erro que a aplicação Node.js precisa capturar e tratar adequadamente.

Para mitigar deadlocks em ambientes de alto volume, a regra de ouro é padronizar a ordem de acesso aos recursos em toda a base de código da API. Se todas as rotas da aplicação sempre atualizarem os registros na mesma sequência numérica de IDs — independentemente da ordem em que o usuário enviou as requisições —, a chance de um impasse diminui drasticamente. Além disso, manter as transações o mais curtas possível reduz a janela de vulnerabilidade onde os bloqueios permanecem ativos.

Impactos de Latência e Níveis de Isolamento

O nível de isolamento de transação escolhido no PostgreSQL dita como uma transação enxerga as alterações feitas por outras transações em tempo real. O nível padrão, Read Committed, garante que dados sujos não sejam lidos, mas permite que uma mesma consulta retorne valores diferentes se executada duas vezes na mesma transação, fenômeno conhecido como leitura não repetitiva. Por outro lado, o nível Repeatable Read garante consistência absoluta ao longo de toda a transação, mas aumenta drasticamente o risco de falhas de serialização sob carga intensa.

Na prática, escolher o isolamento correto é um exercício constante de ponderação entre consistência estrita de dados e capacidade de atendimento da API. Sistemas financeiros exigem níveis mais altos de isolamento, enquanto redes sociais toleram leituras ligeiramente desatualizadas em troca de latências menores. Entender esses trade-offs evita que o banco de dados vire o principal gargalo de gargalo de performance conforme a infraestrutura da empresa escala.

Estratégias de Retry e Recuperação de Falhas

Quando ocorrem falhas por concorrência otimista ou impasses resolvidos por deadlock, a API Node.js não deve simplesmente retornar um erro genérico de servidor para o cliente final. A arquitetura backend precisa prever mecanismos inteligentes de nova tentativa, conhecidos como retry policies. Na prática, isso significa que a camada de persistência intercepta o erro específico do banco, aguarda alguns milissegundos com variação aleatória de tempo e tenta executar a transação novamente de forma transparente.

Essa técnica, combinada com algoritmos de backoff exponencial, evita que centenas de requisições falhadas batam no banco de dados ao mesmo tempo em um efeito cascata destrutivo. Implementar uma política robusta de retry garante que picos momentâneos de tráfego sejam absorvidos pela aplicação sem intervenção humana, elevando a resiliência operacional do sistema distribuído a patamares profissionais.

Considerações Finais

O gerenciamento eficiente de concorrência em APIs Node.js conectadas ao PostgreSQL exige muito mais do que apenas escrever consultas SQL corretas. Envolve compreender profundamente o comportamento físico do banco de dados, antecipar cenários de contenção e escolher conscientemente entre abordagens otimistas e pessimistas conforme o domínio de negócio. Ao aplicar estratégias consistentes de bloqueio, controle de versão e políticas de nova tentativa, engenheiros conseguem construir sistemas resilientes capazes de suportar cargas massivas sem comprometer a integridade dos dados.

O futuro da engenharia backend sob alta escala depende da capacidade de projetar arquiteturas resilientes a falhas transitórias. Dominar os conceitos de isolamento transacional e mitigação de deadlocks transforma o desenvolvedor em um profissional capaz de sustentar o crescimento de grandes produtos tecnológicos com segurança, previsibilidade e alta performance operacional.