9 Padrões de Concorrência em Backend que Você Precisa Dominar

Concorrência em backend não é só executar tarefas em paralelo: é coordenar processos que competem por recursos compartilhados. Sem os padrões certos, deadlocks, race conditions e dados inconsistentes viram rotina. Abaixo, os 9 padrões que todo dev backend precisa conhecer, do mais básico ao mais estratégico.

1. Thread Pool

Controla quantas threads executam simultaneamente, evitando que o sistema crie milhares de threads e consuma toda a memória. Em vez de criar uma thread por requisição, o pool reusa um número fixo de workers. Aplicações web comuns usam pools de 10 a 50 threads por núcleo, o Tomcat, por exemplo, usa 200 threads por padrão. Sem pool, um pico de 500 requisições simultâneas pode derrubar o servidor.

2. Lock Otimista vs. Lock Pessimista

Lock pessimista bloqueia o recurso antes de usar, ideal quando a contenção é alta e conflitos são frequentes, como em reservas de assentos. Lock otimista permite leitura simultânea e verifica conflito só na escrita, via versão ou timestamp. Bancos como PostgreSQL e MySQL oferecem ambas estratégias. Em sistemas de e-commerce com muitos reads e poucos writes concorrentes, o lock otimista reduz latência em até 40%.

3. Fila de Mensagens

Desacopla produtores de consumidores: requisições entram na fila e são processadas assincronamente. RabbitMQ, Kafka e SQS são exemplos clássicos. Útil para tarefas demoradas (envio de email, geração de relatório) que não precisam de resposta síncrona. Uma fila bem configurada suporta picos de 10x a carga normal sem queda de performance.

4. SAGA (Coreografia ou Orquestração)

Gerencia transações distribuídas sem locks globais. Cada serviço executa sua operação e publica um evento; se algo falha, uma ação compensatória desfaz o que foi feito. Em sistemas de microsserviços, o padrão SAGA evita deadlocks entre serviços que antes usavam transações XA. A orquestração centraliza o fluxo; a coreografia distribui a lógica entre os serviços. Em ambos, a consistência eventual é aceita.

5. Ator (Actor Model)

Cada entidade concorrente é um ator que recebe mensagens, processa e envia respostas, sem compartilhar estado. Akka, Erlang e Orleans implementam esse modelo. A grande vantagem: elimina locks porque cada ator processa uma mensagem por vez. Útil em sistemas de chat, jogos multiplayer e qualquer cenário com muitas entidades independentes.

6. Backpressure

Quando um produtor gera dados mais rápido que o consumidor consegue processar, backpressure sinaliza para o produtor reduzir o ritmo. Sem isso, filas enchem, memória estoura e o sistema crasha. Reactive Streams (Java) e RxJS implementam backpressure com operadores como buffer, throttle e drop. Em pipelines de streaming, backpressure evita OOM e mantém latência previsível.

7. Semáforo

Controla acesso a um recurso limitado, como conexões de banco ou sockets, permitindo que N threads usem simultaneamente. Diferente de lock (que permite só um), o semáforo libera até N acessos. Em APIs que consomem serviços externos com rate limit, o semáforo evita que o backend exceda o limite. Exemplo: 5 conexões simultâneas a um banco MySQL.

8. Pipeline (Processamento em Estágios)

Divide uma tarefa em estágios encadeados, cada um executado por uma thread ou grupo de threads. O padrão é comum em processamento de imagens, ETL e compiladores. Cada estágio tem seu próprio buffer de entrada. A latência total é a soma dos estágios, mas a taxa de transferência pode ser maior que a execução sequencial pura. Cuidado com gargalos no estágio mais lento, ele dita o throughput.

9. Leituras Consistentes (Read Replicas e Cache com Invalidação)

Para sistemas com muitas leituras e escritas esporádicas, replicar dados em caches (Redis, Memcached) ou read replicas reduz contenção no banco principal. O desafio é manter a consistência: se um dado é atualizado, o cache precisa ser invalidado. Estratégias como TTL curto, write-through e cache-aside resolvem. Em sites de catálogo, 90% das requisições podem ser servidas por cache sem tocar no banco.

Qual padrão escolher?

Se o gargalo é contenção de recurso, comece com Thread Pool e Semáforo. Para transações distribuídas, SAGA ou Ator. Se o problema é volume de dados, invista em Fila + Backpressure. E nunca esqueça: concorrência bem feita é a que ninguém percebe, o sistema escala sem que o usuário sinta latência ou perca dados.

Perguntas Frequentes

O que é concorrência em backend?

Concorrência é a capacidade de um sistema gerenciar múltiplas tarefas ao mesmo tempo, compartilhando recursos (CPU, memória, banco) de forma coordenada. Diferente de paralelismo (que executa tarefas literalmente ao mesmo tempo em múltiplos núcleos), concorrência lida com a coordenação do acesso a recursos compartilhados.

Qual a diferença entre lock otimista e pessimista?

Lock pessimista bloqueia o recurso antes da operação, garantindo exclusividade. Lock otimista permite leitura simultânea e verifica conflito apenas na escrita, usando versão ou timestamp. O pessimista é mais seguro em alta contenção; o otimista é mais rápido quando conflitos são raros.

Quando usar fila de mensagens em vez de thread pool?

Fila de mensagens é indicada para tarefas assíncronas que não precisam de resposta imediata (envio de email, processamento de imagem). Thread pool é para tarefas síncronas que exigem resposta rápida, como atender requisições HTTP. A fila desacopla produtor e consumidor; o pool apenas gerencia threads.

O padrão SAGA funciona para microsserviços?

Sim, é o padrão mais adotado para transações distribuídas em microsserviços. Ele evita locks globais usando compensações em caso de falha. A orquestração centraliza o fluxo em um serviço; a coreografia distribui a lógica entre os serviços. Em ambos, a consistência é eventual.

Como backpressure evita queda de sistema?

Backpressure sinaliza ao produtor para reduzir a taxa de envio quando o consumidor está sobrecarregado. Sem ele, filas crescem sem limite, consumindo memória até o crash. Implementações com Reactive Streams ou operadores de throttle mantêm a taxa de processamento estável.

Cache com read replicas resolve concorrência?

Sim, reduz a contenção no banco principal ao servir leituras de réplicas ou cache. O desafio é manter a consistência: quando um dado é atualizado, o cache precisa ser invalidado. Estratégias como TTL curto, write-through e cache-aside garantem que o dado não fique obsoleto por muito tempo.