Forem: Pablo Jonatan

Garantindo a idempotência de eventos com Redis

Pablo Jonatan — Tue, 27 Sep 2022 11:31:32 +0000

Importante: Esse artigo assume que o público alvo tem algum conhecimento prévio relacionado a:

Eventos
Processamento assíncrono
APIs
Redis
Kafka.

Introdução

Quando se fala em processamento assíncrono, é comum que se fale em eventos. Eventos são ações que ocorrem em um determinado momento e que podem ser disparados por uma ação ou por um evento externo e o processamento dele pode ser feito em um momento posterior.

Mas o que é Idempotência?

Conceito de idempotência, segundo a Wikipédia:

Idempotência é a propriedade que algumas operações têm de poderem ser aplicadas várias vezes sem que o valor do resultado se altere após a aplicação inicial.

No contexto deste artigo, iremos utilizar o conceito de idempotência como parte de uma estratégia para evitar o processamento repetido de notificações.

Contextualização

Faço parte de um time que, entre outras aplicações, é dono de uma API responsável por receber notificações via webhook com o intuito de publicá-las em tópicos do Kafka, consumidos por outras aplicações, como, por exemplo, um worker responsável por tratar e enviá-las para vários destinos, como o Open Search do time, um Data Lake compartilhado com a companhia e alguns webhooks de outros squads.

Problema

Uma das premissas é que nenhuma notificação pode ser perdida, por isso, temos, em nossos workers, estratégias como Retries e DLQs para garantir que, mesmo que qualquer parte do processo falhe, a notificação será enviada para o destino. Além disso, por lidarmos com fontes externas que enviam dados via webhook, há a possibilidade de que falhas na comunicação entre os softwares façam com que esses dados, vez ou outra, sejam processados mais de uma vez. Assim, chegamos na seguinte pergunta:

Como garantir que uma notificação será processada apenas uma vez?

Solução

Para garantir que uma notificação não será enviada duas vezes para o mesmo destino, utilizamos o Redis para armazenar informações sobre as notificações que já foram enviadas. Quando uma notificação é enviada, ela é armazenada no Redis. Quando uma notificação é reprocessada, verificamos se ela já foi enviada para o Redis. Se ela já foi enviada, não precisamos enviá-la novamente. Se ela ainda não foi enviada, precisamos enviá-la.

Exemplo fictício

Nome da API: payment-api,
Tipo da Notificação: paymentNotification,
Descrição: API que recebe informações de pagamentos realizados por todas as lojas de uma companhia via webhook.
Schema: ```JSON

{
"id": "number",
"date": "string",
"method": "string",
"installments": "number",
"store_id": "number",
}

**Importante:** Nesse exemplo, assumimos uma **premissa** que `id` é único apenas para o contexto da loja que o gerou, representada por `store_id`, e durante a data que foi gerado, `date`. 

### Geração da chave do Redis
Para as notificações do tipo paymentNotification, recebidas via webhook por payment-api, foi gerada uma lista com o número mínimo de suas propriedades que, juntas, formam uma chave idempotente.

Considerando a **premissa** que assumimos, as propriedades eleitas para formar uma chave idempotente seriam:
- `id`
- `store_id`
- `date`

Isolando às três propriedades em um novo objeto, teríamos algo como:
```JSON


{
  "id": 123,
  "store_id": 123456789,
  "date": "2022-01-01T00:00:00.000Z"
}

E essa seria a chave:



123-123456789-2022-01-01T00:00:00.000Z

Nesse exemplo temos apenas a payment-api, porém, em um cenário real, poderíamos ter uma instância do Redis compartilhada por várias APIs, cada uma com suas próprias entidades de domínio, portanto, com suas próprias listas de propriedades que formariam uma chave idempotente.

Dado esse cenário onde pode-se ter várias APIs utilizando um Redis compartilhado, para evitar conflitos podemos adicionar, por exemplo, o nome da API e o tipo da notificação como prefixo da chave idempotente, ficando assim: :nome_api-:tipo_notificacao-:id-:store_id-:date.

Com a nova adição a chave ficou assim:



payment-api-paymentNotification-123-123456789-2022-01-01T00:00:00.000Z

Porém, tendo em vista que date não será lida por humanos, podemos simplificar a chave e utilizar seu valor em milissegundos.
Agora essa é a nova chave:



payment-api-paymentNotification-123-123456789-1640995200000

Mas qual parte do dado usar como valor?

Agora que já temos a chave, precisamos definir o valor que será armazenado nela, para isso, precisamos entender o que queremos que aconteça quando uma determinada notificação for reenviada. Entre as opções, temos:

Armazenar o valor da resposta retornada quando a notificação foi enviada pela primeira vez.
Armazenar o valor true ou 1 para indicar que a notificação já foi enviada.

Analisando as opções

A primeira opção é interessante, pois, caso uma notificação seja recebida mais de uma vez, poderemos retornar o mesmo valor sem processá-la novamente, tendo em vista que, pode ser que o remetente esteja reenviando a notificação porque não recebeu a primeira resposta ou algo do tipo. Porém, essa opção tem um problema: o valor pode ser muito grande, o que pode gerar um problema relacionado a espaço, por exemplo.
A segunda opção é mais simples, porém, do ponto de vista do espaço, é bastante eficiente, se tornando tão interessante quanto a primeira opção em alguns contextos, por exemplo, num caso em que o remetente não aguarda uma resposta ou aguarda uma resposta padrão, como 200 OK.

Opção escolhida

No ponto de vista da payment-api que foi citada como exemplo, a segunda opção foi escolhida, pois não há um remetente aguardando uma resposta específica, portanto, não há necessidade de armazenar o valor da resposta.

Desenho da solução

Armazenando referências de notificações no Redis

A ideia principal é que quando uma requisição via webhook chegar para payment-api, a API irá gerar a chave idempotente e, caso ela não exista no Redis, irá processar a requisição e armazenar suas referências nele, caso contrário, irá retornar a resposta default, que será 200 OK e adicionar um log que a requisição foi ignorada, pois já foi processada. No momento que já temos a chave, o valor e a certeza de precisamos armazená-los, utilizamos o comando SET do Redis, que recebe como parâmetros a chave e o valor.

Expirando a chave

Agora que já temos chave e valor armazenados no Redis, precisamos definir o tempo de expiração da chave. Para isso, utilizamos o comando EXPIRE do Redis, que recebe como parâmetros a chave e o tempo de expiração em segundos. No caso do exemplo, iremos definir uma expiração de um dia, ou seja, 86400 segundos.

Resumindo

Gerar a chave idempotente
Verificar se a chave existe no Redis
Caso não exista, processar a requisição e armazenar a chave no Redis com um tempo de expiração de um dia
Caso exista, retornar a resposta default e adicionar um log que a requisição foi ignorada, pois já está no Redis

Conclusão

Esse é um exemplo de como utilizar o Redis para evitar que requisições via webhook sejam processadas mais de uma vez, porém, esse não é o único cenário em que o Redis pode ser utilizado, ele pode ser utilizado para muitas outras coisas, como, por exemplo, para armazenar dados de sessão, dados de autenticação, dados de cache, etc.

Espero que tenham gostado do artigo, qualquer dúvida ou sugestão, podem deixar nos comentários.

Como a comunidade brasileira utiliza o twitter para aprender em público

Pablo Jonatan — Thu, 24 Feb 2022 03:52:05 +0000

Contextualização

Durante os últimos anos puderam-se ver a popularização das profissões relacionadas ao desenvolvimento de software devido a tópicos quentes, como, blockchain, serviços em nuvem, o crescente aumento das oportunidades (e salários) para desenvolvedores e a possibilidade de carreira global.

O contexto abordado fez com que muitas pessoas, de diversas idades, optassem por realizar transição de carreira ou iniciar nas carreiras relacionadas a Tecnologia da Informação. Contudo, ensino superior ainda é um tema delicado, tendo em vista que muitas pessoas não têm acesso à universidade, seguindo um caminho menos tradicional.

Felizmente, desde os primórdios da computação, existe a forte ideia de disseminar o conhecimento e o incentivo ao aprendizado autodidata, que juntos a conceitos como aprender em público, estão facilitando a entrada dos brasileiros na área, além de projetos como a Universidade Brasileira Livre, que “organiza o conteúdo online em pt-BR para aumentar o acesso de brasileiros a educação”.

O intuito deste artigo é explicar o que é o cc @sseraphini do twitter, qual sua proposta e como isso tem funcionado para alguns brasileiros.

O que é o cc @sseraphini

As pessoas que utilizaram o twitter nos últimos meses podem ter se deparado com tweets de conteúdos relacionados a tecnologia da informação carregando o sufixo cc @sseraphini.

// Detect dark theme var iframe = document.getElementById('tweet-1486119328063926272-954'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1486119328063926272&theme=dark" }

O “cc” é a já conhecida abreviação de “com cópia” geralmente utilizada em emails, agora aplicada no Twitter. Explicando de maneira simples, atribuir tal sufixo a um tweet é uma forma do autor alcançar as dezenas de milhares de pessoas que seguem o Sibelius (criador do cc @sseraphini) já que ele impulsiona essas publicações através de like e retweet, com a finalidade de mostrar o conteúdo para mais pessoas que possam ajudar a sanar dúvidas, debater sobre o tema e/ou se beneficiar das informações publicadas.

O processo do retweet é manual, portanto, o próprio Sibelius lê os tweets, repassa para que a comunidade contribua e muitas vezes participa junto à comunidade.

É uma relação onde todos saem ganhando:

Aqueles com dúvidas conseguem avançar ou encontrar um ponto de partida para analisar melhor o problema;
Aqueles que respondem conseguem disseminar e fortalecer seus conhecimentos;
Aqueles que esbarram com os tweets na sua linha do tempo podem adquirir algum conhecimento;
Todos os envolvidos aprendem algo;
Possibilidade de networking e engajamento;
Escrever sobre um problema pode fazer com que o entenda melhor.

Colaboração no sseraphini.cc

Conforme relatado por seu criador no fio “cc @sseraphini 1 month project”, o site foi lançado tendo apenas um botão com o intuito de tornar mais simples a ação de tuitar usando o supracitado sufixo e algumas issues em seu repositório do GitHub.

Após o lançamento da versão, rapidamente a comunidade começou a contribuir, os desenvolvedores assumiram o controle das issues e com os pull requests o site recebeu novas funcionalidades logo nos primeiros dias. Atualmente, com quase dois meses de existência, o repositório tem 15 issues abertas e 29 já fechadas, contando com a contribuição de desenvolvedores de diferentes níveis de experiência.

Uma dessas funcionalidades permite filtrar os tweets recentes por palavras-chave, conforme a figura:

O projeto também conta com uma extensão para navegadores baseados em chromium, sendo uma versão simplificada do site.

Como a comunidade vem utilizando o recurso

A recepção positiva que o sseraphini.cc obteve ao ser lançado é um reflexo da popularidade do cc @sseraphini na comunidade do Twitter, conhecida como bolha dev. Dessa forma, muitas pessoas aderiram ao sufixo e estão utilizando-o para, principalmente:

Perguntar sobre dúvidas técnicas;
Debater conceitos;
Compartilhar artigos e dicas;
Oferecer e procurar mentoria;
Divulgar vagas de emprego.

Basicamente, as pessoas utilizam o Google e demais serviços de busca, Stack Overflow, GitHub, YouTube, livros e outros meios para obter informação, porém, perceberam que podem utilizar o cc @sseraphini para ter uma visão mais dinâmica sobre os conteúdos, permitindo até comparar as experiências relatadas e suas pesquisas, para assim conseguir alcançar melhores resultados e qualidade nos estudos.

É importante ressaltar que o espaço não é restrito ao idioma português do Brasil, diversos membros da comunidade costumam perguntar e responder em inglês, para incentivar o entendimento da língua e para os tweets alcançarem pessoas de todo o mundo, aumentando a possibilidade de obterem respostas.

Conclusão

Tendo em vista que o mercado de desenvolvimento de software está bastante aquecido e há uma evasão de talentos do Brasil para suprir a demanda global, projetos que visam engajar a comunidade e construir conhecimento são bastante úteis, dessa forma, o cc @sseraphini vem incentivando o aprender em público e o aprendizado contínuo para os seus usuários, mesmo enquanto no Twitter.

Além disso, o sseraphini.cc permite que os desenvolvedores que contribuem com o site adquiram experiência em um projeto real e de código aberto, construindo funcionalidades ao lado de profissionais experientes, aprendendo com eles e construindo diariamente sua prova de esforço para, por exemplo, lutar pela primeira vaga de emprego.

No entanto, é necessário haver uma autocrítica de cada usuário em relação aos tweets.

Se for perguntar, dê o máximo de detalhes possível. Por exemplo, em um tweet sobre erros no código:

Compartilhar informações necessárias para análise do problema;
Mostrar partes relevantes do código;
Explicar o que está tentando fazer;
Explicar quais soluções já tentou e o resultado.

Entre os que respondem também há espaço para autocrítica, podendo-se focar em:

Evitar ser agressivo (ou passivo-agressivo);
Entender que as pessoas podem discordar de você e aprender com isso;
Quando a pergunta incomodar, deixe-a para outro responder.

Forem: Pablo Jonatan

Garantindo a idempotência de eventos com Redis

Introdução

Mas o que é Idempotência?

Contextualização

Problema

Solução

Exemplo fictício

Mas qual parte do dado usar como valor?

Analisando as opções

Opção escolhida

Desenho da solução

Armazenando referências de notificações no Redis

Expirando a chave

Resumindo

Conclusão

Como a comunidade brasileira utiliza o twitter para aprender em público

Contextualização

O que é o cc @sseraphini

Colaboração no sseraphini.cc

Como a comunidade vem utilizando o recurso

Conclusão

Referências