DEV Community: Joel Filho

Idempotência: Melhorando a Resiliência de Seu Sistema - Parte II

Joel Filho — Sun, 21 Jul 2024 23:40:15 +0000

No post anterior, discutimos os conceitos básicos de Resiliência e Idempotência. Além disso, demonstrei como apliquei esses conceitos de forma prática em um projeto pessoal.

Agora, explorarei algumas limitações do modelo inicialmente proposto e apresentarei uma alternativa viável para implementar idempotência, que é mais performática.

Quais são as limitações de gerar a Chave de Idempotência no Front-end?

No modelo proposto anteriormente, a chave de idempotência é gerada pelo front-end, armazenada no SessionStorage do navegador e posteriormente enviada ao back-end. Embora essa abordagem funcione, não é a mais adequada para resolver o problema.

Primeiramente, a geração da chave pelo front-end permite que o usuário do sistema a manipule, já que é facilmente acessível ao abrir a aba de armazenamento do navegador.

Em segundo lugar, e estritamente relacionado ao primeiro ponto, como o front-end está mais suscetível a manipulações e ataques cibernéticos. Por padrão, regras de negócio não devem ser estabelecidas no front-end. Caso haja necessidade, elas devem ser reforçadas no back-end.

Qual seria a solução?

A primeira solução, mais simples, seria criar um endpoint no back-end para gerar a chave de idempotência e armazená-la em memória. Nesse caso, poderíamos utilizar a abordagem de gerar um UUID como chave de idempotência.

A segunda, mais robusta, é utilizar uma camada de cache para armazenar a chave de idempotência por um tempo pré-estabelecido. Nesse caso, a chave de idempotência poderia ser criada a partir de um hash das informações da conta do remetente, do destinatário, do valor e da descrição (se houver). Essa chave seria armazenada em um Redis, por exemplo, por 5 minutos (ou qualquer outro período de tempo, dependendo da implementação). Caso a requisição se repita devido a alguma instabilidade, a chave será buscada no cache e a transação será encontrada.

Na segunda proposta, não optei por gerar um UUID a cada transação. Isso se deve ao fato de que, se um UUID for gerado a cada requisição para criar uma transação, mesmo que uma requisição seja duplicada, ainda assim seriam duas requisições diferentes, resultando em UUIDs distintos. Dessa forma, nossa chave de idempotência não seria verdadeiramente idempotente.

Por que essa é uma melhor solução?

Primeiro, porque eliminamos a necessidade de um campo correspondente à chave de idempotência no banco de dados, evitando sobrecarregar o banco de dados principal com consultas para verificar se a transação já existe. A consulta ao Redis é muito mais rápida, performática e menos custosa.

Segundo, porque retiramos qualquer regra de negócio do front-end, evitando assim que nosso sistema esteja mais vulnerável a ataques e manipulações indesejadas dos dados.

Como implementar essa solução?

Primeiro, vamos instalar o Redis no nosso projeto NodeJS:

pnpm add ioredis

Vamos criar uma instância do Redis:

import Redis from 'ioredis';

const redis = new Redis();

Agora, vamos criar o hash que será nossa chave de idempotência:

import crypto from 'node:crypto';

async createTransaction(data, ctx) {
  ...
  const { value, description } = data;

  const dataToBeHashed = `${senderAccount._id}-${receiverAccount?._id}-${value}-${description}`

  const idempotentKey = 
  crypto.createHash('sha256').update(dataToBeHashed).digest('hex')

  ...
}

Em seguida, definimos essa chave de idempotência no cache e verificamos sua existência:

async createTransaction(data, ctx) {
   ...

   const existingTransaction = await redis.set(idempotentKey, 'transaction', 'EX', 60 * 5, 'GET')

   if (existingTransaction) {
     return false
   }
   ...
}

Esta foi uma demonstração simples de como essa abordagem pode ser implementada com NodeJS, independentemente do framework utilizado, seja Express, NestJS, Koa ou Fastify.

Essa implementação ainda não está disponível no repositório do projeto, mas pretendo trabalhar nisso nos próximos dias.

Esta série de posts foi criada para compartilhar minha jornada no desenvolvimento deste projeto e as decisões que tomei com base em meus estudos e reflexões.

Estou aberto a feedbacks e novas propostas. Pretendo implementar novas features futuramente, então estou à disposição para conversar mais sobre isso no meu LinkedIn.

Idempotência: Melhorando a Resiliência de Seu Sistema - Parte I

Joel Filho — Sun, 21 Jul 2024 23:39:03 +0000

À medida que seu software cresce, é crucial aplicar dois conceitos fundamentais no desenvolvimento: Resiliência e Idempotência.

Esses conceitos trabalham juntos em harmonia. Hoje, vou apresentar uma breve introdução a esses conceitos e compartilhar como os apliquei de forma prática em meu projeto de simulação bancária, onde implementei a criação de transações entre diferentes contas de forma idempotente.

Confira o projeto no meu GitHub e no repositório bank.com.br.

Resiliência

Resiliência é a capacidade do seu software de falhar e lidar bem com essas falhas. Para desenvolver um software resiliente, a equipe deve antecipar possíveis falhas e planejar como resolvê-las. Todos os sistemas estão sujeitos a falhas, mas o que os diferencia é a capacidade de tratar e resolver esses problemas de maneira eficiente. =)

Idempotência

Idempotência é a propriedade que algumas operações têm de poderem ser aplicadas várias vezes sem alterar o resultado após a aplicação inicial. Em outras palavras, uma operação idempotente pode ser repetida inúmeras vezes e o estado do sistema permanecerá o mesmo.

Por exemplo, no contexto da aplicação desenvolvida, a idempotência foi aplicada no seguinte cenário: Digamos que uma conta A está fazendo uma transação de R$10,00 para a conta B. Porém, por uma inconsistência nos servidores, essa transação foi realizada duas vezes, fazendo com que o valor enviado para a conta B dobrasse para R$20,00. Isso representa um problema significativo, especialmente em transações maiores. A idempotência pode ser aplicada para prevenir essas duplicações.

Mas como aplicar esses conceitos, na prática?

Recentemente, trabalhei em um projeto pessoal, o Bank, onde a proposta foi simular o dia-a-dia de um banco, realizando transações entre diferentes contas. As tecnologias utilizadas no projeto foram: React, Relay, GraphQL, KoaJS e MongoDB.

Primeiramente, criei o model utilizando o mongoose, referente às contas que seriam criadas no sistema, contendo as seguintes informações:

Identificador Único da Conta
Número da Conta
O CPF/CNPJ (taxId) do usuário

Em seguida, foi criado o model das transações:

Identificador Único da Transação
O identificador da conta do remetente
O identificador da conta do destinatário
O valor a ser transferido
Chave de Impotência
Descrição da Transação (Opcional)

Podemos perceber, no model de Transação, que há um campo chamado “Chave de Idempotência”. A criação e utilização desse campo no nosso banco de dados representa a estratégia de idempotência utilizada no desenvolvimento do sistema. Existem algumas estratégias para isso, como: Idempotency Key (padrão utilizado), Get Or Create, Histórico de Chamadas, dentre outros.

De forma geral, será gerada uma Chave de Idempotência (única) para verificar se uma transação já foi realizada anteriormente. A Chave de Idempotência deve ser única para o contexto específico de uma transação. Em uma transação, temos informações que definem seu contexto, como a conta do remetente, a conta do destinatário e o valor. Isso significa que a chave de idempotência deve ser única para uma transação que envolva essas informações. Para uma discussão detalhada sobre o assunto, acesse a seguinte issue do repositório do projeto, criada pelo @caiocampoos

Para implementar isso, defini um índice composto no meu Schema, entre essas informações:

TransactionSchema.index(
  { senderAccountId: 1, idempotentKey: 1, receiverAccountId: 1 },
  { unique: true }
);

Para receber essa Chave de Idempotência, optei por recebê-la no header "idempotentkey". Essa escolha será discutida mais detalhadamente em uma publicação futura.

Agora, na criação da Transação, fiz a seguinte verificação:

const existingTransaction = await TransactionModel.findOne({
   idempotentKey,
   senderAccountId: senderAccount?._id,
   receiverAccountId: receiverAccount?._id,
});

if (existingTransaction) {
   return {
     transactionId: existingTransaction?._id,
   };
}

Observe que retorno o identificador da transação criada anteriormente com as mesmas informações, mas também poderia lançar uma exceção. Tudo depende do contexto da aplicação e de qual abordagem é a melhor para você.

Para criar a chave de idempotência no front-end da aplicação, escrevi o seguinte código:

import { v7 as uuid } from "uuid";

const createIdempotencyKey = () => {
  const idempotencyKey = uuid();
  sessionStorage.setItem("idempotent-key", idempotencyKey);
};

Armazenei a Chave de Idempotência no SessionStorage do navegador quando o usuário decide criar uma transação e, ao fazer a requisição, pego esse valor e envio no cabeçalho para o back-end. Dessa forma, garanto que essa Chave de Idempotência seja utilizada apenas naquele contexto, visto que, diferentemente do LocalStorage, esse dado só estará disponível para aquela sessão enquanto ela existir (ou até a informação ser sobrescrita).

Porém, pesquisando um pouco mais e refletindo melhor sobre essas ideias, conclui que essa abordagem pode ter certas limitações, que trataremos no próximo post.

Fontes

Guia de Introdução ao Docker

Joel Filho — Sun, 09 Apr 2023 00:53:10 +0000

Quando falamos de Docker, uma das primeiras coisas que nos vem à mente são containers. Basicamente, quase tudo em Docker se resume a containers, então, é super importante que você tenha esse conceito bem sólido na sua mente e não só isso, mas também como funcionam.

Como funcionam os containers?

Para explicar o conceito de containers, podemos começar pelo sistema operacional (SO) - tendo como base para a explicação o Linux, especificamente - ser composto de processos e subprocessos. Para entender melhor esse conceito, precisamos entender os três principais pilares que os sustentam: Namespaces, CGroups _e _Overlay File System (OFS) que falaremos a seguir.

Namespaces:

A partir desses processos, surgiu os chamados Namespaces, que, basicamente, atuam no isolamento de cada processo. Nesse caso, há uma hierarquia entre os processos-pai e os processos-filhos, onde estes últimos são altamente dependentes dos primeiros e, caso aconteça algo aos processos principais, todo o meu sistema operacional vai à baixo. Tendo isso em mente, os Namespaces isolam cada processo do SO, permitindo que cada um rode de forma independente. Em outras palavras, um container emula um SO com processos rodando em isolamento e executando tarefas diferentes. Containers não executam um SO completo, mas apenas os elementos específicos necessários, incluindo o kernel.

CGroups:

Para entender o funcionamento do CGroups e para quê eles servem, pensemos na seguinte ocorrência: Temos alguns containers rodando (sabendo que containers são, basicamente, processos isolados que possuem subprocessos) e, em um deles, temos um enorme vazamento (leak) de memória, o que consequentemente acaba afetando os outros processos fora desse Namespace. É aí que entram os CGroups. Eles surgiram para controlar e isolar os recursos de cada Namespace, para que esses recursos sejam bem distribuídos para cada um, de acordo com suas necessidades e, não só isso, para que os seus recursos não afetem o funcionamento de outros processos fora desse Namespace.

File System → Overlay File System (OFS)

Novamente, vamos contextualizar o funcionamento do Overlay File System para uma melhor compreensão: Digamos que temos um container em que estamos rodando uma aplicação de, aproximadamente, 95mb (Megabytes), porém, para que essa aplicação funcione corretamente, é necessário a utilização de duas dependências diferentes.
A partir disso, podemos citar o seguinte possível acontecimento: surgiu a necessidade de mudar essa aplicação e, para isso, teremos que criar outra imagem a partir da que temos atualmente (falaremos sobre imagens no próximo tópico). Então, o Overlay File System (OFS) será usado para criar imagens desse novo aplicativo executável. Isso é possível porque ele pode gerar uma nova imagem a partir de uma existente, apenas alterando as partes que precisam ser atualizadas, sem a necessidade de reinstalar as dependências obrigatórias.

Agora que conhecemos um pouco sobre o funcionamento dos containers e de seus 3 pilares, podemos adentrar um pouco mais em outro tópicos importantes quando o assunto é Docker, bem como o conceito de Imagens & o tão importante DockerFile.

Imagens

De forma bem objetiva, podemos definir as imagens como um “pacote” executável (ou um conjunto de dependências encadeadas) que possui todos os requisitos/dependências necessários(as) para rodar um aplicativo, incluindo, um arquivo de configuração, variáveis de ambiente, bibliotecas e assim por diante.

DockerFile

Para a criação de imagens, utilizamos o DockerFile. Basicamente, ele é um arquivo declarativo que cita instruções ao container Docker de como será criada e “buildada” a referente imagem que queremos criar.
De maneira usual, (quase) sempre criamos uma imagem a partir de outra imagem já existente, com suas devidas dependências pré-definidas e configuradas e vamos moldando-a de acordo com nossa necessidade.

Abaixo segue um exemplo de modelo de uma implementação do DockerFile, Vamos explicar linha a linha o que cada uma faz e sua respectiva função:

FROM node:16.18.0-alpine as base
RUN npm install

EXPOSE 3000

Essa primeira linha (logo abaixo) é de extrema importância, pois referencia ao DockerFile a imagem base utilizaremos para a criação da nossa.

FROM node:16.18.0-alpine as base

Aqui, dizemos ao DockerFile que será necessário que ele rode esse comando determinado, lembrando: você pode determinar que sejam executados mais de um comando, dessa forma:

RUN npm install
RUN npm run build

E, por último (não é o último comando que podemos determinar ao DockerFile e, sim o último de minha demonstração), podemos expôr portas em que essas imagens estarão rodando para que possamos acessá-las quando quisermos:

EXPOSE 3000

Acredito que agora você já possui conhecimento suficiente para aprofundar-se nos estudos em Docker e, caso precise de alguma ajuda com algum conteito ou recomendação de cursos sobre o assunto, me manda solicitação no meu LinkedIn, que ficarei feliz em ajudá-lo. Além disso, espero que esse post tenha sido de muita ajuda e estarei sempre disposto a receber feedbacks!