Idempotência - A necessidade de garantir integridade em chamadas distribuídas

        Idempotência significa que executar a mesma operação várias vezes tem o mesmo efeito que executá-la uma única vez. Para escrever um CRUD que não permita entradas duplicadas por falha de rede, reenvio automático, duplicidade, etc é preciso atenção na implementação e usar alguns padrões. 

        Podemos usar Chaves Naturais: Quando um recurso já possui um identificador natural único (como CPF, CNPJ, número de contrato, e-mail, matrícula etc.), podemos utilizá-lo como chave principal no cadastro. Isso elimina a possibilidade de duplicidade no nível lógico do sistema.

        Controle de Duplicidade no Banco de Dados: está bem ligada com a primeira opção, já que quando usamos chaves naturais costumamos controlar via banco como PK ou pelo menos unique constraint. Mas aqui também pode estrapolar esse conceito e usar outros campos em constraints, criandopadrões que não podem se repetir. Dependendo do caso uma data ou outro campo podem ser usados para criar essa verificação no Banco de Dados, e ao tentar inserir os dois registros irá barrar.

        Outra opção usada é a “Idempotency Key” (chave única por requisição). O cliente gera uma chave única (ex: UUID) e a envia no cabeçalho da requisição, então o servidor armazena o resultado da primeira requisição associada a essa chave e se a mesma chave for usada novamente, o servidor retorna o mesmo resultado, sem processar a operação novamente.

      Onde essa chave é armazenada? No Banco de Dados ou Cache Distribuído (Redis, Memcached, etc.). Dependendo da aplicação, pode-se guardar nos 2 locais. Uma terceira opção seria a sessão do usuário, para aplicações web autenticadas.

        Para o caso de clique nervoso do usuário, desabilitar o botão no momento do clique até que volte uma resposta também pode ajudar. Isso também vai depender da situação, do sistema, etc., mas sim, para alguns casos, desabilitar o botão enquanto o servidor responde pode resolver muita coisa. 

Outbox Pattern - Salve antes de qualquer coisa!

        Em sistemas distribuídos, nos micro serviços, algumas transações abrangem vários serviços, e é comum (e recomendado) que cada um deles tenha seu Banco de Dados, e sua forma de tratar a informação.

            O padrão Outbox nada mais é do que salvar os dados em uma tabela antes de enviar para o próximo passo. Desta maneira, caso ocorra uma falha no serviço que tem a mensagem antes dele repassar, os dados estão garantidos. Depois um JOB faz a leitura dos dados e vai enviando para o brocker ou fazendo o que tiver que fazer, podendo tentar novamente quantas vezes necessário. 

       Caso ocorra algum problema, os dados estão no banco para serem reprocessados. Após o processamento ocorrer com sucesso, os dados podem ser apagados com segurança!

            Isso também serve para aliviar a carga do microsserviço, por exemplo, uma API que tem que receber os dados em grande volume e tratá-lo pra enviar para os próximos serviços, poderia receber e guardar rapidamente no Banco de Dados e então um JOB em segundo plano faz essa parte, estando o processo da API livre para próxima requisição.

        Trabalhei em um sistema onde determinada API recebia os dados, um lote de até mil contas, gerava o Tracer ID, e um ID de lote, validava uns 5 campos de cabeçalho, salvava no banco, depois fazia o repasse para o broken, que então o microsserviço consumia, pegava o lote, dividia conta a conta fazendo validações primárias, e enviava para os microsserviços (eram 2, um de cada área da empresa) fazerem o devido processamento conta a conta. Após o processamento de cada conta, cada microsserviço de área, enviava para o microsserviço de resposta o resultado, que era atualizado no banco de dados (aquele primeiro, usado pela API para guardar a entrada). Lá, depois de todo lote processado, o status do lote era alterado para a situação correspondente (sucesso, sucesso parcial, falha, etc). A qualquer momento poderia se consultar o status do lote na API. Nesse caso, os dados da tabela de entrada tinham controle de status e não eram apagados. A necessidade de apagar ou não, varia de acordo com o negócio. Pode ser que seja interessante manter ou não, em outros quem sabe manter por uns dias apenas?

        Pra esse artigo é só! 

Aplicações Distribuídas - Usando lock distribuído para gerenciar processamento de dados

        Um dos motivos de eu escrever esse Blog, na verdade o principal deles, é eu ter conteúdo pra mim mesmo de uma forma rápida e fácil, pois na nossa área tem coisas que fazemos e depois esquecemos, ou vemos em algum lugar e quando precisamos não conseguimos encontrar. Esse é um desses casos. Essa publicação surgiu de uma palestra que vi do Rafael Ponte no canal da Zup Innovation no youtube que deixo o link no final e aconselho bastante que assistam. Aqui é apenas um resumo para consulta rápida.

         Um problema comum quando trabalhamos com a aplicações distribuídas é quando temos um JOB ou algo do tipo que precisa realizar um determinado processamento de dados e precisamos garantir que esse processamento seja único para cada registro ou linha da tabela.

        Em uma aplicação com uma única instância podemos fazer isso com o synchronized do Java e vida que segue, mas, hoje normalmente trabalhamos com mais de uma instância da aplicação e aí as coisas complicam um pouco. O synchronized resolve para uma única instância mas não tem controle sobre outras execuções, o que nos faz ter que buscar outras soluções.

        Se os dados que precisam ser processados podem ser processados por uma única instância sem criar gargálos, temos por exemplo soluções como:

•         Eleger um servidor como responsável por executar esse JOB. Essa eu já usei e é bem comum. Pode-se ter uma tabela de parâmetros no banco com o IP de um servidor específico e o JOB checa se o IP cadastrado é o daquela instância, caso seja, ele executa. Pode-se ter uma propriedade no banco (não necessariamente o IP) e outra com mesmo valor em um arquivo de config, ao ler e comparar as duas, sendo iguais, o servidor executa.
• Usar o próprio banco de dados para gerenciar o lock. Assim, o próprio banco locka os dados enquanto estiverem sendo usados naquela transação. Esse modo basta adicionar uma anotação na consulta:

       

        No caso, diretamente no SQL ficaria assim:

        Lembrando que, é preciso garantir que os métos e a atualização sejam eficientes para não locar os registros por muito tempo. Ou seja, o uso do @Transaction precisa ser feito de forma eficiente, ficando apenas a parte necessária da operação dentro da transação. Na Aula o Rafael até mostra uma forma de como fazer isso também.

        Agora, quando os dados precisam ser processados de forma paralela por mais de uma máquina, temos outras soluções a considerar.

• Uma máquina lê os dados e distribui para as outras processarem. Dependendo do volume de dados e outras variáveis, essa solução era muito usada antes das mensagerias. Uma máquina lê os dados e chama uma outra máquina de uma lista de máquinas disóníveis para executar o processamento. Por exemplo, uma companhia telefônica que precisa realizar o faturamento de clientes tem um JOB que levanta os IDs dos clientes e distribui para outras máquinas processarem o faturamento daqueles clientes. O ponto ruim é que essa "máquina gerente" acumula muita responsabilidade e pode ser um gargalo. Esse trecho de código que levanta os dados só pode rodar em uma única instancia para não duplicar o processamento.
• Podemos usar soluções de filas e mensagerias. Soluções como Kafka ou outras.
• Podemos usar o Lock do banco de dados de forma otimizada. Essa é a solução apresentada pelo Rafael. Para isso, acrescenta-se o ao lock do banco a possibilidade de pular os dados locados e pegar o próximo. Vamos ver o que precisa ser adicionado em termos de anotação Java:

        E no SQL diretamente ficaria assim:

        Mais uma vez fica a dica de garantir que o método esteja otimizado, que dentro da tranzação esteja apenas o que precisa estar lá, para que o lock dure apenas o necessário.

        Essa solução é muito interessante porque permite que várias instâncias executem o mesmo código garantindo que os dados serão respeitados por todas elas como mostra a imagem abaixo:

        Aqui temos todo o código de exemplo trazido por ele na aula:

        Aconselho assistir a aula, tem mais coisas interesantes lá!

Link: aula do Rafael Ponte sobre Distributed Scheduling

Versões do OpenJDK para download

         As vezes pra quem está começando pode ser complicado achar onde baixar as versões do Java, então deixei aqui o link que vai direto para a página de downloads do OpenJDK. Basta clicar AQUI.

        Infelizmente, com as diretrizes da Oracle, as versões mais antigas do Java vão ficando indisponíveis mesmo nessa página, como é o caso da versão 8 que até a data de hoje (09/10/2025) ainda é muito usada porém não aparece mais para download. Com isso, é preciso uma busca mais cuidadosa e demorada caso precise de uma versão tão antiga. Talvez ache apenas de outros distribuidores. Sempre pesquise bem antes de confiar!