DEV Community: Francisco Zanfranceschi

Uma Introdução Simples ao RSA

Francisco Zanfranceschi — Mon, 26 May 2025 01:20:31 +0000

Você já deve ter ouvido falar de RSA – aquele negócio de criptografia, chaves assimétricas –, certo? Mas você sabe o que é, como funciona e de onde vem o nome? Nessa thread, vou dar uma visão geral bem simples pra você entender e arrasar no próximo date ou churrasco.

Vamos direto ao ponto! RSA é um algoritmo de criptografia de chaves assimétricas (ou chaves públicas). E chaves assimétricas aqui significa que são valores diferentes, mas matematicamente relacionados pra que a criptografia e descriptografia funcionem certinho.

O nome RSA vem dos sobrenomes dos seus 3 criadores: Ron Rivest, Adi Shamir e Leonard Adleman. RSA é provavelmente o sistema de criptografia mais conhecido atualmente e foi divulgado em 1977.

Voltando na questão das chaves assimétricas ou públicas. Essa parte é interessante porque pra que duas partes se comuniquem de forma segura, elas não precisam compartilhar uma senha – elas compartilham apenas uma informação pública e cada uma tem sua "senha" – chave privada.

Vamos supor que A queira se comunicar com B de forma segura. No RSA, A tem uma chave pública e uma chave privada e B também tem uma chave pública e outra privada. A e B trocam livremente suas chaves públicas. Sem problemas se terceiros acessarem essas chaves públicas.

Quando A precisa enviar uma mensagem pra B, A usa a chave pública de B para criptografar uma mensagem e então a envia para B. B então usa sua chave privada para descriptografar essa mensagem. E vice-versa para quando B quiser enviar mensagens para A.

Tranquilo até aqui?

O algoritmo pra criptografar e descriptografar é super simples. Imaginando que toda informação que trocamos entre computadores seja representada por números, vamos a um exemplo de que "oi" seja representado por 111 e 115.

https://cryptii.com/pipes/text-decimal

As chaves públicas do RSA na verdade são pares de números. Vamos supor que a chave pública seja (143, 17) e a privada seja (143, 113). A fórmula pra criptografar é (para cada caractere):

c ^ 17 mod 143

...onde c é 111 e depois 115

Então "oi" que é 111 e 115, seria representado por 89 e 124. Se formos na tabela ASCII, o valor criptografado seria "Y|".

Pra descriptografar, a fórmula usa valores da chave privada:

d ^ 113 mod 143

...onde d é 89 e depois 124

Vamos descriptografar 89 e 124 então:

89 ^ 113 mod 143 = 111
124 ^ 113 mod 143 = 115

Tá-dá! Temos 111 e 115 de novo que representa "oi"!

A parte que acho mais legal do RSA é a geração das chaves. Mas como já existem muitos materiais na internet sobre como fazer isso, fiz apenas uma representação visual porque não achei nada assim e talvez isso te ajude a entender.

https://www.cryptool.org/en/cto/rsa-step-by-step/

Bom, isso aqui foi o básico do básico sobre RSA de uma forma extremamente simplificada.

O RSA tem umas coisas bem interessantes que valem ser mencionadas. Continua aqui pra você ser a pessoa mais legal no jantar do natal desse ano e soltar essas pros seus primos.

A fortaleza do RSA é ser baseado em números primos e seu produto. Isso porque fatorar dois números primos gigantes (n) é extremamente custoso. Um computador normal levaria muuuuito tempo pra fazer isso. Com computadores quânticos o negócio já muda de figura.

Se alguém descobrir um algoritmo pra quebrar o número n em q e p, basicamente a segurança da maioria da internet estaria seriamente comprometida. Ou você acha mesmo que não têm governos que interceptam mensagens criptografadas e guardam tudo pra tentar descriptografar? Humpf...

Outra coisa interessante sobre RSA é que as chaves são comutativas no sentido que a chave pública pode ser usada também pra descriptografar algo que foi criptografado com a chave privada. E isso é usado para assinaturas.

Ou seja, de forma simplificada, eu criptografo algo com minha chave privada e qualquer um poderia descriptografar com minha chave pública para comprovar minha autenticidade. Por exemplo, isso é usado em emails.

RSA ainda é muito usado. Por exemplo, no TLS 1.2, o RSA pode ser usado pra troca de chaves.

Se achou esse conteúdo legal, posso te sugerir algumas coisas:

Procure por detalhes relacionados a RSA em certificados de sites – p.ex. a chave pública (geralmente em formato hexadecimal).
Escreva o algoritmo para gerar chaves e (des)criptografar na sua linguagem favorita.

Muito obrigado se leu até aqui!

Acesse https://gist.github.com/zanfranceschi/aae284f2446adf00c0bc240d2d43cf33 para um exemplo prático em Python.

[Conceito] - Índice de Instabilidade de Software

Francisco Zanfranceschi — Sat, 10 Aug 2024 22:30:21 +0000

Conteúdo original em https://twitter.com/zanfranceschi/status/1822399151998636165

Estou elaborando um material que menciono o Índice de Instabilidade de software que é:

Ce / (Ce + Ca)

Onde:
Ce = Acoplamento Eferente
Ca = Acoplamento Aferente

O resultado vai de 0 a 1 e quanto mais próximo de 0, mais estável e vice-versa. Mas você entende o por quê disso?

Quote de https://twitter.com/zanfranceschi/status/1543662061095227392

↓

A gente nota que com essa fórmula, quanto maior o número de dependências (acoplamentos) eferentes em relação às eferentes, mais instável o resultado é (próximo de 1). E o inverso também é verdadeiro.

Isso acontece por dois motivos:

- Quanto maior o número de dependências que nosso componente tem de outros (eferentes), mais suscetível à falhas; e

- Quanto maior o número de outros componentes que dependem da gente (aferentes) mais estável a gente precisa ser.

Pelo que sei, esse índice foi criado pelo Robert C. Martin (?). Mas o conheci por um texto do
@elemarjr.

Esse índice pode ser aplicado a muitas coisas (de classes a serviços e além), tem algumas limitações e acho válido falarmos sobre elas também.

https://arquiteturadesoftware.online/volume-1/nunca-ignore-o-acoplamento-capitulo-4-v1-03/

Por exemplo, um componente com 0 dependências aferentes, e 1 ou 1000 eferentes vai ter o mesmo índice máximo de instabilidade, mas na prática um componente com 1000 dependências é muito mais frágil do que um com 1.

Então se decidir aplicá-lo, tenha isso em mente!

/fim

[Desafio] - "Low Level" toInt Function

Francisco Zanfranceschi — Fri, 02 Aug 2024 16:43:55 +0000

Conteúdo original em https://x.com/zanfranceschi/status/1819413388360810601

Ei dev,

Um desafio "low level" pra você.

Crie uma função toInt que transforma strings numéricas (ex. "42") em números inteiros SEM usar funções embutidas/nativas da sua lang como int, intval, parseInt, etc.

Dica: talvez você precise se apoiar numa tabela de caracteres.

[Conceito] - Meus 3 Tipos Preferidos de Diagramas

Francisco Zanfranceschi — Sat, 06 Jul 2024 17:58:20 +0000

Conteúdo original em https://x.com/zanfranceschi/status/1809646770361614528

Ei dev,

Vou compartilhar com você os tipos de diagramas que mais gosto e uso para desenhar soluções novas ou mapear soluções existentes.

Segue o fio. 🧵

Antes de mais nada, acho importante saber diferenciar desenhos ESTRUTURAIS e COMPORTAMENTAIS. Então se você não sabe, vale a pena dar uma lida sobre isso antes de prosseguir – já escrevi sobre isso nessa thread. 👇

Depois volta aqui.

https://x.com/zanfranceschi/status/1515015604977401857

DIAGRAMAS DE SEQUÊNCIA

De longe, esse é o diagrama que mais uso. Pra mim, ele é muito útil pra desenhar integrações entre serviços/aplicações.

Também é possível desenhar interações entre componentes dentro da mesma aplicação (no mesmo processo), mas raramente faço isso.

DIAGRAMAS DE COMPONENTES

Acho um bom diagrama pra mostrar dependências entre serviços. É uma visão estática que oferece um bom contexto duma solução. Diria que é uma alternativa mais técnica e menos descritiva aos primeiros níveis do modelo C4 do @simonbrown.

DIAGRAMA DE MÁQUINA DE ESTADOS

Uso com menos frequência, mas acho ele muito útil pra quando preciso modela ou entender os possíveis estados de algo mais complexo. Desenhá-los me ajuda a fixar e/ou fomentar o entendimento dessas coisas mais complexas.

Pra mim, essa é a frequência de uso dos diagramas:

SEQUÊNCIA: muito frequente
COMPONENTES: frequente (geralmente após desenhar diagramas de sequência)
ESTADOS: pouco frequente (apenas quando preciso desenhar algo complexo o suficiente pra ser difícil de lembrar/decorar)

FERRAMENTAS

Eu praticamente só uso o drawio justamente por ter um bom suporte aos diagramas de sequência.

Dá pra fazer bons diagramas com mermaid ou plantuml – eles são bons porque você não perde tempo com alinhamentos. Mas são menos flexíveis e ficam ruins com modelos grandes.

Muita gente usa excalidraw, miro, etc. Mas por causa da falta de suporte ou suporte ruim aos diagramas de sequência, raramente uso essas ferramentas.

Cada pessoa se dá melhor com diferentes diagramas e o essencial no final é sempre se comunicar bem – com qualquer notação!

Fim.

[Conceito] - Não Use HTTP 404 ou 204 para Buscas Sem Resultados

Francisco Zanfranceschi — Tue, 04 Jun 2024 03:45:15 +0000

Conteúdo original em https://x.com/zanfranceschi/status/1797835707962245352

Ei dev,

Bora falar um pouco de semântica HTTP e porque acho FEIO retornar um 404 numa busca sem resultados?

No HTTP, uma imagem, uma folha de estilos, um arquivo javascript e detalhes de um usuário em formato JSON são todos igualmente considerados RECURSOS. TUDO É RECURSO!

🧵

E como TUDO É UM RECURSO, um endpoint de busca também é um recurso por si só!

Vamos supor os seguintes endpoints:

GET /users/:id - retorna detalhes de um usuário.
GET /users?q=:termo - retorna o resultado duma busca.

Dado que todos nós concordamos que GET /users é um recurso (certo?), o CONTEÚDO desse recurso, que é o resultado duma busca, por exemplo, pode ou não conter informações em formato de lista sobre usuários com atributos que se assemelham ao termo usado na query string 'q'.

O retorno de GET /users?=berto poderia ser algo como:

[{"nome": "Roberto"}, {"nome": "Adalberto"}]

E uma chamada para o mesmo recurso de busca com parâmetros diferentes – GET /users?=jubis – poderia retornar algo como:

[]

...uma lista vazia.

GET /users é um recurso – sempre!

404 é considerado um erro de quem chama seu servidor informando um recurso inexistente! O recurso de busca tá lá, o que não tá é o usuário com o nome Jubiscleiton que você colocou no parâmetro de busca. Faz sentido?

Se você é (era?) do time 404, espero ter te convencido de que uma busca é um recurso por si só.

Agora vou falar com você que é do time 204. Fica junto, cola na grade.

"Ain, mas não tem resultado, então não tem conteúdo, então é 204" ouço você resmungar. Rola pra baixo. ↓

SEMANTICAMENTE, a gente usa 204 pra quando estamos cagando para o (não) conteúdo.

Por exemplo, quando você manda um PUT /users/1, foda-se o corpo porque você sabe o novo estado do recurso. Tudo que importa é um retorno HTTP com status 204 dizendo que sua requisição deu certo. 👍

E num recurso que retorna, p.ex., uma lista (vazia ou não), você se importa com o corpo. É muito mais uniforme verificar o tamanho da lista do resultado da busca, por exemplo. Do contrário, você teria que verificar o status code pra ver se tem itens na lista. ↓

if vote 200t
then prinltn(data)
else if vote 204t
then "sem resultados"

🙄

Pra finalizar, uma singela homenagem ao @leandronsp:

Poesia "Pelo Reconhecimento da Busca Como um Recurso" by Zan:

GET /users/:id é a comida
GET /users?q=:termo é o pote
E o pote vazio
Não deixa de ser um pote

Mais uma coisa: se você tá mexendo num legado que retorna 404 ou 204 pra uma busca vazia e simplesmente não existe benefício em mudar isso, não sofra. O que importa em primeiro lugar é funcionar – seja com 404 ou 204, sinceramente.

Muito obrigado se chegou até aqui.

E não esqueça de deixar seu like, se inscrever no canal, e ativar o sininho pra você não vídeo novo do canal.

😗

[Desafio] - Race Condition em Sistemas Distribuídos

Francisco Zanfranceschi — Thu, 04 Jan 2024 22:42:19 +0000

Conteúdo original em https://twitter.com/zanfranceschi/status/1743040590751977636

Ei dev,

Eu tenho a solução para sua falta de novos problemas! Yey 🥹

Cola aqui pra resolver esse desafio de RACE CONDITION em um SISTEMA DISTRIBUÍDO de compras.

↓

DISCLAIMER: É um cenário simplificado e hipotético. (O diagrama tá em inglês porque vocês são tudo metido a besta, mas saibam que prefiro em pt_BR 💅).

Acredito que esse desafio seja adequado pra quem já é pleno – talvez os sandy e júnior sofram um pouco pra resolvê-lo.

CENÁRIO: Um conjunto de aplicações com serviços assíncronos de cadastro de cliente e processamento de pagamentos de compras.

However, existe a premissa de que um cliente já esteja persistido no banco do serviço de pagamentos para que os pagamentos sejam processados.

E para que essa premissa seja satisfeita, o serviço de cadastro emite um evento sempre que um cliente for cadastrado. A imagem mostra esse fluxo.

(Obs.: Esse padrão em que serviço de pgto guarda uma referência do cliente se chama "Event-Carried State Transfer" – já falei sobre.)

https://twitter.com/zanfranceschi/status/1511294401603006465

O PROBLEMA:

Só que para novos clientes, às vezes acontece do comando para processar o pagamento ser consumido antes do consumo do evento de cadastro do cliente. Temos aí um cenário de RACE CONDITION! Ebaaa! 🥲

E aí, o pessoal te incumbiu de resolver esse problema.

E pro problema ficar ainda mais problemático (afinal queremos problemas aqui, não é mesmo?), te pediram pra evitar o uso de banco de dados para essa resolução – lhe pediram para que use outras filas (??).

E aí, dev com tempo livre em busca de problemas, como resolve isso?!

Muito obrigado a você que chegou até aqui!!! ♥️

[Conceito] - Lock Pessimista x Otimista: Desenvolvendo Senso Analítico

Francisco Zanfranceschi — Wed, 03 Jan 2024 04:51:43 +0000

Conteúdo original em https://twitter.com/zanfranceschi/status/1742406772139430162

Ei dev,

Esses dias postei provocações sobre lock otimista x pessimista. Alguns disseram que até certo nível de concorrência/conflito uma opção vale mais a pena que outra.

Vamos pensar nisso juntos? Não vou dar uma resposta – quero apenas aprofundar nosso senso analítico.

↓

https://twitter.com/zanfranceschi/status/1738927304372371552

DISCLAIMER: Essa thread vale mais a pena se você souber pelo menos por cima o que é um lock otimista e um lock pessimista de banco de dados. Se não souber e mesmo assim quiser continuar lendo, tem todo meu apoio. rsrs

Mas sério, dá uma pesquisada – não são conceitos difíceis.

→ O primeiro passo é termos números concretos. Bora pensar um pouco sobre a probabilidade de conflitos. Pra isso, vamos imaginar o seguinte cenário: requisições simultâneas para comprar algum produto – para simplicidade, vamos imaginar que todos os produtos vendem a mesma coisa.

Vamos então supor que temos 10 requisições simultâneas para 8 produtos diferentes. Queremos calcular a probabilidade de p.ex. 2 dessas requisições concorrerem para afetar o estoque do mesmo produto. Lembre-se, é um cenário síncrono e simplista!

Para chegar nisso, precisamos achar o número de combinações de conflitos (R ÷ C × P × P ^ (R - C)) e dividí-lo pelo número total de combinações (P ^ R), onde R = número de requisições simultâneas, P = produtos disponíveis, C = número de conflitos.

R ÷ C × P × P ^ (R - C) / P ^ R

Meio mala essa fórmula, eu sei. O resultado dela é 0,625 – ou seja, ~62% de chance de conflito/concorrência com os parâmetros mencionados. Se quiséssemos a probabilidade com, p.ex., 3 conflitos, essa porcentagem cairia para ~5%; com 4, iria para ~0,4%. Com 5, 4,8828125E-4. 🥲

Agora a gente precisa entender quanto tempo >MAIS OU MENOS< cada abordagem – pessimista e otimista – leva pra processar cada requisição.

Vamos começar pela abordagem pessimista chutando um valor para o processamento da requisição: ~10ms. Como existe a concorrência de 2 requisições, a gente teria por cima um tempo de processamento de ~20ms para as 10 requisições simultâneas.

Se fossem 3 conflitos, ~30ms; 4, ~40ms para 10 requisições; e assim por diante. Por favor, note que essa é uma estimativa simplificada.

Nesse cenário pessimista, a gente geralmente precisa de menos mecanismos para tratar problemas de inconsistência nos dados.

Lembre-se, estamos fazendo mais locks para termos mais consistência de dados ao preço de uma possível maior contenção – menos paralelismo.

Bora pro otimismo – aqui a porca torce o rabo. No cenário Poliana, a gente geralmente introduz mais mecanismos para compensar os conflitos/não possibilidade de realização dos comandos no banco. Isso pode se traduzir em retentativas, rollbacks, mensagens de erro, etc, e etc.

Pra nossa comparação fazer sentido, deveríamos incluir o tempo de processamento desses possíveis mecanismos de compensação. Por exemplo, 1 retentativa automática pode levar o dobro do tempo; 2 retentativas o triplo; devolver uma mensagem de erro pode ser muito rápido, etc.

Se devolver uma mensagem de erro, talvez não haja acréscimo de tempo como há para uma compensação automática, mas talvez o usuário final o irá fazer manualmente gerando mais requisições subsequentes. Isso tudo precisa ser considerado. 🤔

A maior diferença entre os dois cenários é que o pessimista é (mais ou menos) mais serial durante os conflitos (porque há o lock de mais registros) e o cenário pessimista é menos serial porque um processo interfere menos em outros (não há lock por toda a transação).

Uma estimativa super simplificada do cenário otimista, onde apenas uma mensagem de erro é devolvida, se tivéssemos 2, 3 ou N conflitos simultâneos e cada processamento levasse ~10ms, nós ainda teríamos os mesmos ~10ms para as 10 requisições simultâneas – com ou sem conflitos.

Vou deixar pra você fazer um exercício sobre como calcular o cenário otimista duma maneira melhor, pois estou com 2% de life estatística. 🙂

Espero que agora você tenha pelo menos uma intuição sobre alguns cálculos para obter números relevantes.

Obviamente, num cenário real muitas outras dimensões seriam consideradas. P.ex.: produtos que vendem mais (ponderação), picos de acesso, promoções, publicidade, etc. Em outros domínios, outras dimensões devem ser consideradas.

O resumo é o seguinte:

- Tente se basear em números;
- Entenda as dimensões específicas do seu problema/domínio;
- Faça experimentos! A prática muitas vezes nos dá insights muito mais tangíveis do que algumas teorias, ainda mais quando não temos experiência.

Talvez eu tenha sido filosófico/genérico demais nessa thread porque na verdade muita coisa nela serve pra outras coisas não relacionadas a simplesmente escolher entre usar uma abordagem de lock pessimista x otimista de banco de dados (inclusive, existem abordagens híbridas!).

Mas olha só: muito obrigado se você chegou até aqui – mesmo!

Um abraço pra quem é de abraço e um beijo pra quem é de beijo. ♥️

[Desafio] - Engenharia Reversa De Algoritmo

Francisco Zanfranceschi — Mon, 20 Nov 2023 14:49:23 +0000

Conteúdo original em https://twitter.com/zanfranceschi/status/1726613006921150913

Ei dev,

Pega esse desafio de engenharia reversa.

1. Explique o que a função "f(units input) → output" está fazendo apenas olhando os exemplos das imagens.

2. Se achou fácil, implemente a função – experimente com e sem recursão. E não esqueça de postar pra gente ver!

↓

[Conceito] - Como Atuar com Arquitetura

Francisco Zanfranceschi — Tue, 18 Jul 2023 01:27:30 +0000

Conteúdo original em https://twitter.com/zanfranceschi/status/1681112067934396416

Ei dev,

Algumas pessoas me perguntam sobre arquitetura – pedem algum direcionamento, livros, cursos, etc.

Tenho cerca de 10 anos de experiência atuando exclusivamente com arquitetura e o começo foi difícil porque é uma disciplina sem muito material explicitamente dedicado.

↓

DISCLAIMER 1: O assunto aqui é arquitetura de sistemas, integrações, solução. Não é sobre a organização de código – arquitetura de aplicação, software.

DISCLAIMER 2: É o meu ponto de vista, a minha experiência individual.

Vou começar pela conclusão: é uma disciplina/área que dificilmente no início você vai se sentir preparada/o.

Se já estiver dando seus primeiros passos nessa direção e tiver aquela sensação de estar perdida/o, saiba que isso é mais normal do que imagina.

EXPERIÊNCIA PRÁTICA

Arquitetura (ou "System Design" que está mais na moda) é difícil praticar porque os desafios estão justamente na escala, no longo tempo de execução dos sistemas, na operação, etc. Coisas que um localhost ou apenas uma conta na AWS não vão te oferecer.

ABRANGÊNCIA DE CONHECIMENTO

Cada empresa pode – e geralmente vai – exigir diferentes níveis de conhecimento em diferentes subáreas para quem exerce a disciplina de arquitetura. Existem empresas com times dedicados à rede, então p.ex. uma arquiteta talvez não precise conhecer [+]

muita coisa ou até mesmo não tenha autonomia para decisões nessa subárea. O mesmo pode acontecer com bancos de dados, armazenamento, identificação/autenticação/autorização, etc.

Na minha experiência, geralmente quanto maior a empresa, mais as coisas já estão resolvidas por times dedicados.

Em empresas menores, geralmente você terá uma atuação mais abrangente e aprofundada – você precisará conhecer mais sobre mais coisas.

CONTEXTO

Um desenho pode funcionar muito bem em uma empresa, mas não em outra. O código de uma API tem mais chances de funcionar bem em mais lugares. Arquitetura é sobre contexto: vendors, suporte, operação, orçamento, infra, etc. Já um código é algo mais especializado/focado.

Você precisa desenhar a solução de acordo com as ferramentas, suporte, conhecimento das pessoas, e qualquer outro tipo de recurso disponível para aquele contexto. Não adianta colocar Kubernetes que funciona super bem para uma empresa numa empresa que não tem a capacidade e/ou [+]

intenção de manter uma tecnologia dessas. gRPC pode ter sido uma escolha muito boa na sua empresa anterior, mas na atual pode simplesmente não fazer sentido. E assim por diante.

Ou seja, contexto e restrições – que podem ser a mesma coisa no final do dia.

HÁ ESPERANÇA

Mas nem tudo é uma mudança drástica ou uma experiência completamente diferente de empresa para empresa. Com o passar do tempo e acúmulo de experiência, você nota que muitas coisas mais fundamentais são iguais nos desenhos de solução de diversas empresas.

Vê-se que para um tipo de cenário, p.ex. o processamento assíncrono é mais adequado, e usar Kafka, RabbitMQ, uma fila em banco de dados é mais um detalhe de implementação. E assim o é com muitas outras coisas – segurança, processamento em lote, redes pública vs privada, etc.

Ou seja, a cada novo desenho, novo projeto, você pode aprender mais um pouquinho e usar um pouco do que já aprendeu. É um ciclo que vai – mais ou menos rapidamente dependendo da sua exposição à coisas novas – preenchendo alguns buracos de conhecimento dessa estrada.

CARGO/DISCIPLINA

Algumas empresas possuem o cargo para arquitetura, outras empresas incorporam a arquitetura como uma disciplina aplicada pela engenharia. No começo, não se preocupe muito com títulos, se preocupe com o aprendizado.

E COMO APRENDER?

A pergunta de milhões! Não existe uma resposta, mas uma forma de aprender é manter a curiosidade, buscar entender como as coisas funcionam. Se você é dev, procure entender onde e como as aplicações que desenvolve funcionam. Se envolva com times e pessoas com [+]

conhecimentos diferentes dos seus. Fale com DBAs, pessoal de segurança, de foundation, etc. Se junte com pessoas que exercem a disciplina de arquitetura. Tente fazer um desenho de algo que já sabe como poderia funcionar – talvez algo mais simples no início.

Arquitetura/System Design é uma jornada gradual e às vezes mais ambígua do que programação justamente pela quantidade das dimensões/interpretações que podem ser menos objetivas para um desenho (pessoas, contratos, restrições, suporte, etc.).

Tenha paciência! Eu nunca vi uma arquiteta ou arquiteto júnior, mas todo mundo envelhece e fica mais experiente. 🙃

E muito obrigado por ter lido até aqui! ♥️

[Desafio] - Agregação de Registros

Francisco Zanfranceschi — Fri, 14 Jul 2023 14:04:26 +0000

Conteúdo original em https://twitter.com/zanfranceschi/status/1679497149732585472

Ei dev,

Pega esse desafio de agregação de registros!

Dado registros granulares que contêm data e quantidade, crie uma função que os agregue por data em um dicionário e some os atributos "qtd". O código a seguir explica melhor o desafio.

# dado os seguintes registros
registros = [{"data" : "2023-07-13", "qtd" : 12},
             {"data" : "2023-07-14", "qtd" : 30},
             {"data" : "2023-07-13", "qtd" : 4},
             {"data" : "2023-07-14", "qtd" : 98},
             {"data" : "2023-07-12", "qtd" : 4},
             {"data" : "2023-07-12", "qtd" : 8},
             {"data" : "2023-07-12", "qtd" : 31},
             {"data" : "2023-07-15", "qtd" : 74},
             {"data" : "2023-07-13", "qtd" : 12},
             {"data" : "2023-07-12", "qtd" : 1},
             {"data" : "2023-07-17", "qtd" : 3},
             {"data" : "2023-07-16", "qtd" : 35}]

# desenvolva uma função de agrupamento
resultado = agrupar(registros)

# que retorne o seguinte resultado
{"2023-07-13" : 28,
 "2023-07-14" : 128,
 "2023-07-12" : 44,
 "2023-07-15" : 74,
 "2023-07-17" : 3,
 "2023-07-16" : 35}`

Se alguém tiver curiosidade sobre como isso poderia ser feito em Clojure, aí está.

(defn agrupar
  [registros]
  (into {} (map (fn [i]
                  [(first i)
                   (->> (map :qtd (second i))
                        (reduce +))])
                (group-by :data registros))))

(agrupar [{:data "2023-07-13", :qtd 12}
          {:data "2023-07-14", :qtd 30}
          {:data "2023-07-13", :qtd 4}
          {:data "2023-07-14", :qtd 98}
          {:data "2023-07-12", :qtd 4}
          {:data "2023-07-12", :qtd 8}
          {:data "2023-07-12", :qtd 31}
          {:data "2023-07-15", :qtd 74}
          {:data "2023-07-13", :qtd 12}
          {:data "2023-07-12", :qtd 1}
          {:data "2023-07-17", :qtd 3}
          {:data "2023-07-16", :qtd 35}])

[Desafio] - Algoritmo Round-Robin Pica-Pau

Francisco Zanfranceschi — Sat, 08 Jul 2023 16:50:07 +0000

Conteúdo original em https://twitter.com/zanfranceschi/status/1677719152545636352

Ei dev,

Pega esse desafio do algoritmo Round Robin do Pica-Pau!

Faça um algoritmo de distribuição/ciclo da mesma forma que o Pica-Pau fez com o lobo do episódio: "1 pra mim, 1 pra você; 2 pra mim (pegando 2 itens), 2 pra você (dando apenas 1 item)".

cc @sseraphini

↓

O resultado precisa ser algo como na imagem aqui.

Escolhi Python pro exemplo/guia porque é uma lang fácil de ler, mas obviamente faça com sua lang preferida.

Posta aí depois a presepada que você fez!

😗

Ah, me esqueci. Se quiser saber o que é um algoritmo round-robin que não seja zoeira, olha essa thread aqui.

https://twitter.com/zanfranceschi/status/1525916697332371457

[Desafio] - 10 Desafios Simples de System Design: Resolução 5/9 (Integração com Eventos via Webhook)

Francisco Zanfranceschi — Fri, 07 Apr 2023 17:51:50 +0000

Dando continuidade às discussões sobre os 10 Desafios Simples de System Design, esse post é sobre Integração com Eventos via Webhook (parte 5/9).

[Desafio] - 10 Desafios Simples de System Design

Francisco Zanfranceschi ・ Mar 21 '23

Para ser capaz de resolver esse desafio, é importante primeiramente entender o que é uma Arquitetura Orientada a Eventos. Não é o objetivo desse material se aprofundar nesse assunto, mas – superficialmente falando – eventos são como notificações de coisas que ocorreram (um usuário cadastrado, um pagamento realizado, etc.). Um sistema/arquitetura sem eventos, geralmente é um sistema baseado apenas em comandos (cadastre um usuário, faça o pagamento, etc.). Comandos existem mesmo numa arquitetura orientada a eventos e são geralmente as fontes geradoras de eventos.

No mundo corporativo, geralmente webhooks são usados para integração/notificação de eventos entre sistemas de empresas diferentes localizados em redes diferentes. Isso ocorre porque webhooks nada mais são do que chamadas HTTP e HTTP é possivelmente o protocolo mais usado, conhecido, e interoperável que existe.

Sistemas corporativos que residem na mesma rede/da mesma empresa frequentemente usam middlewares específicos de mensageria como o Kafka, RabbitMQ, IBM MQ, etc. Dessa forma, outro ponto importante nesse desafio é entender que provavelmente haverá integração entre sistemas que residem em redes diferentes quando se usa webhooks.

A integração via eventos através de middlewares específicos de mensageria nos oferece muitas vantagens – mecanismos de tratamento de erros, retentativas, garantias de entrega, etc, são algumas delas. O material seguinte fala um pouco sobre isso.

[Conceito] - Filas de Retry e Dead-Letter

Francisco Zanfranceschi ・ May 6 '22

Sendo assim, um dos principais desafios em uma integração via webhooks é o tratamento de erros. O que ocorre se o endpoint de callback estiver indisponível? Algumas integrações mais robustas com webhooks oferecem retentativas. Ou seja, se o endpoint não responder à requisição com um status code HTTP na faixa 200 haverá requisições posteriores. É de suma importância considerar esse aspecto de tratamento de indisponibilidade e erros.

Outro ponto importante é o tempo de resposta desejado para o endpoint do webhook. Talvez o endpoint de callback precise responder em um tempo máximo estipulado, caso contrário poderá ocorrer timeout da parte de quem fez a requisição (client timeout).

Bom, considerando a questão de tratamento de erros e tempos de resposta, uma abordagem comum para endpoints de callbacks é não realizar o processamento de forma síncrona durante o ciclo de vida da requisição, mas enviar os eventos recebidos para um processamento assíncrono, inclusive se apoiando em middlewares de mensageria já citados aqui. Dessa forma, a única operação de I/O durante o ciclo de vida da requisição seria enviar o evento para outro componente para processamento posterior (banco de dados, fila, etc.).

A segurança é um aspecto fundamental para esse problema. Considere sobre o endpoint de callback estar em uma rede pública ou conexão privada entre redes diferentes, tokens de acesso, revogação de tokens, VPNs, mTLS, regras de firewall com ranges de IPs de empresas, etc.

O desafio proposto direciona para a elaboração do endpoint que receberá os eventos, mas elaborar uma solução do ponto de vista de quem notifica os eventos (realiza os callbacks) pode ser bem interessante também. Por exemplo, como será feita a retentativa, qual intervalo entre elas, etc.

O material seguinte aborda sobre questões de retentativas.

[Conceito] - Backoff e Jitter

Francisco Zanfranceschi ・ Jun 6 '22

Bom, é isso o que tinha para falar sobre integração via webhooks. Com certeza há muito mais aspectos do que os abordados aqui, mas espero que esse conteúdo tenha lhe dado uma boa intuição sobre os desafios da integração via webhooks.