DEV Community: Tarcisio Araújo

Pagamentos idempotentes: Um Study Case de Arquitetura com Redis e Banco de Dados

Tarcisio Araújo — Sat, 02 May 2026 13:59:43 +0000

Recentemente, passei por um daqueles momentos em que o mesmo conceito começa a aparecer em contextos completamente diferentes e, quando isso acontece, geralmente é um sinal de que vale a pena prestar atenção.

A bola da vez foi: idempotência.

Na aula de compiladores da faculdade: idempotência
Vídeo novo do Augusto Galego sobre: idempotência
Problema específico no trabalho, o que faltava? Idempotência

Mas enfim, o que significa isso?

Idempotência é uma propriedade da matemática e da computação que descreve operações que podem ser executadas uma ou várias vezes, mas produzem o mesmo estado final como se tivessem sido executadas apenas uma vez.

Trazendo isso para o mundo backend, o problema fica mais interessante quando pensamos em operações reais, com efeitos colaterais reais: criar registros, disparar jobs, consumir APIs externas, processar pagamentos ou alterar estados importantes no sistema.

Nesse artigo, vou contar um pouco sobre como estudei esse conceito de forma aplicada, em um cenário real de problema arquitetural.

O caso📋

Para esse estudo, vou apresentar a evolução de um webhook responsável por processar pagamentos. Nesse cenário, consideramos que o processamento assíncrono executa operações custosas, como chamadas para APIs externas.

Por isso, quando a mesma requisição é processada mais de uma vez, seja por instabilidade de rede, retry automático ou falha temporária na comunicação podemos gerar efeitos indesejados, como custo duplicado, inconsistência de dados ou até o processamento repetido de uma operação que deveria acontecer apenas uma vez.

Como eu fiz 👷‍♂️

Comecei implementando o webhook puro, sem nenhuma preocupação com processamento duplicado.

Com a rota funcionando, parti para a implementação de diferentes estratégias para lidar com idempotência na operação. Para isso, criei um middleware responsável por interceptar a requisição antes do processamento principal.

Com o tempo, percebi que esse middleware estava ficando cheio de responsabilidades. Além disso, a própria solução foi atingindo diferentes níveis de maturidade conforme eu entendia melhor o problema.

Foi então que decidi separar a implementação em 4 rotas diferentes, a fim de destacar cada nível:

Sem proteção
Lock temporário com Redis
Idempotência persistente no banco
Idempotência persistente + lock temporário

Fase 1️⃣

Sem mecanismos para idempotência

O problema mora aqui.

Durante o estudo todo vamos considerar a mesma estrutura de payload:

{
  "payer_name": "Fulano Rico",
  "payer_document": "123456",
  "amount_in_cents": 10000,
  "bank_code": "001",
  "branch_number": "1234",
  "account_number": "56789-0"
}

Esse payload representa que o Fulano Rico quer transferir R$ 100,00 para a conta "56789-0".

O problema começa quando lembramos que sistemas distribuídos falham: a rede pode oscilar, a resposta pode demorar, o serviço de origem pode entender que a requisição falhou e, por segurança, reenviar o mesmo evento.

Nesse caso, sem nenhuma implementação para proteção a mesma ação seria processada duas vezes, gerando inconsistências e custos duplicados 🤯

Fase 2️⃣

Redis com hash de payload normalizado

Meu primeiro pensamento foi: “Se o mesmo payload chegar mais de uma vez, vou barrar as próximas requisições e processar apenas a primeira”.

Para começar, precisamos gerar uma chave que identifique a intenção daquele pagamento. Para isso, utilizei a função nativa do PHP hash() para gerar um identificador a partir do payload recebido.

Um detalhe importante aqui é a normalização do payload.

Por exemplo: se o campo payer_name chegar primeiro na primeira requisição e por último na segunda, isso não deveria gerar uma chave diferente. Afinal, apesar da ordem dos campos ter mudado, a intenção da operação continua sendo a mesma.

Por isso, antes de gerar o hash, o payload precisa passar por um processo de normalização, garantindo que a mesma estrutura lógica produza sempre a mesma chave.

Para o payload mencionado na Fase 1, a chave gerada ficaria assim:

"webhook:idempotency:cc4efc0d38d457683b2ece7072e31e55504a04853c48c5799e46921278fff18f"

Com a chave em mãos, o Redis entra como um bloqueio rápido e temporário.

Antes de processar o pagamento, a aplicação tenta salvar essa chave usando SET NX com TTL. O NX garante que a chave só será criada se ela ainda não existir. Na prática, isso significa que a primeira requisição segue o fluxo normalmente, enquanto as próximas, dentro da janela do TTL, são barradas como duplicadas.

Já o TTL evita que essa chave fique registrada para sempre no Redis.

$idempotencyKey = $this->idempotencyKeyGenerator->generate($normalizedPayload);

if (! Redis::set($idempotencyKey, 1, 'EX', 30, 'NX')) {
    return response()->json(['message' => 'Request already processed'], 409);
}

//Posteriormente é realizado um Redis::del($idempotencyKey) caso o processamento em si falhe.

Essa solução é muito eficiente em termos de performance e concorrência imediata, mas levanta alguns pontos de atenção:

O que diferencia um retry do mesmo pagamento de um novo pagamento intencional com os mesmos dados?
Qual deve ser o tempo ideal de duração desse lock?
O que acontece se o processamento demorar mais que o TTL?
O que acontece se a aplicação cair depois de criar a chave, mas antes de concluir o pagamento?

Pensando mais profundamente nessa solução, percebemos uma limitação importante: não temos garantia real sobre a intenção do evento.

Ou seja, dois payloads iguais podem significar a mesma tentativa de pagamento sendo reenviada ou duas tentativas legítimas de pagamento com os mesmos dados.

Fase 3️⃣

Pensando nesse problema, passei a estudar como aplicações reais fazem para diferenciar a intenção da operação.

Uma abordagem comum é utilizar uma Idempotency-Key, enviada pelo consumidor da API, para controlar a unicidade da operação. Esse consumidor pode ser uma máquina de cartão, um gateway de pagamento ou até uma aplicação terceira.

Mas só isso não pareceu suficiente, ainda temos a questão do tempo de bloqueio e a visibilidade de recebimento dos eventos.

Para isso, decidi criar um objeto PaymentWebhookReceipt:

{
  "idempotency_key": "webhook:idempotency:{Hash da Idempotency-Key}", 
  "payload": {
    "payer_name": "Fulano Rico",
    "payer_document": "123456",
    "amount_in_cents": 10000,
    "bank_code": "001",
    "branch_number": "1234",
    "account_number": "56789-0"
  },
  "status": "received",
  "processed_at": null,
  "failed_at": null,
  "failure_reason": null
}

Esse objeto funciona como um recibo do evento recebido. Ele registra informações importantes, como a chave de idempotência utilizada pelo cliente, o payload original, o status do processamento e os dados relacionados ao resultado da solicitação.

A chave de idempotência deve ser única no banco de dados. Dessa forma, se a mesma chave for recebida novamente, a aplicação consegue identificar que aquela operação já passou pelo sistema antes.

Com a possibilidade dos seguintes status:

    case RECEIVED = 'received';
    case PROCESSING = 'processing';
    case PROCESSED = 'processed';
    case FAILED = 'failed';

Ok, mas como ficou esse fluxo na prática?

Um ponto importante é decidir o que acontece quando a operação falha.

A mesma Idempotency-Key pode permitir uma nova tentativa ou exigir uma nova chave, dependendo da regra de negócio.

Agora a identidade da operação está explícita com Idempotency-Key sendo informado pelo cliente, e com o banco de dados como fonte de verdade para saber o status do evento recebido.

Agora temos uma garantia muito mais forte de evitar reprocessamento duplicado da mesma operação.

Porém, toda requisição duplicada tem que chegar no banco dados para conferir a existência. Se pensarmos em um cenário com muitas requisições e muita concorrência isso pode gerar pressão desnecessária no banco de dados.

Fase 4️⃣

Com a solução anterior, temos garantia forte de idempotência, porém podemos melhorar a questão da performance.

Uma solução híbrida, utilizando o Redis para lock rápido e temporário o banco para a rastreabilidade, persistência e fonte de verdade.

Para isso, mantive toda a estrutura de estados da Fase 3, usando o PaymentWebhookReceipt para registrar o ciclo de vida do evento. Também reaproveitei a ideia de lock temporário da Fase 2, mas com uma diferença importante: em vez de gerar a chave a partir do payload, passamos a utilizar a Idempotency-Key enviada pelo cliente.

Além disso, o processo de lock e release também foi melhorado.

Agora, em cada processamento iremos utilizar a seguinte estrutura de chave->valor:

"Idempotency-Key" -> "UUID Gerado na execução para identificar processamento atual"

Dessa forma, o Redis passa a guardar duas informações importantes: a existência do lock e o identificador da execução que está em posse dele naquele momento.

Essa mudança impacta diretamente a forma como fazemos o release do lock. Não basta simplesmente deletar a chave ao final do processamento, porque uma execução atrasada poderia acabar removendo um lock criado por outra requisição.

Por isso, antes de remover a chave, comparamos o UUID da execução atual com o valor salvo no Redis. Essa comparação seguida da remoção precisa acontecer de forma atômica, e é exatamente aqui que entra o script Lua.

if redis.call('get', KEYS[1]) == ARGV[1] then
    return redis.call('del', KEYS[1])
end

return 0

Esse script só remove a chave se o valor salvo no Redis ainda for o UUID da execução atual. Caso contrário, ele retorna 0 e preserva o lock, evitando que uma execução antiga remova o lock de outra.

Assim temos um serviço com as seguintes características:

Eficiente, com Redis fazendo um lock rápido para concorrência em um certo espaço de tempo.
Persistente, com banco de dados como fonte de verdade.
Rastreável, mantendo histórico e status do processamento no PaymentWebhookReceipt;
Mais segura no release do lock, usando Lua para evitar que uma execução remova o lock de outra.

Resultados!

No fim, conseguimos trabalhar diferentes níveis de maturidade do serviço.

Na fase 1 escancaramos o problema.

Na Fase 2, criamos um lock temporário com Redis para lidar com concorrência imediata. Mas ainda pecava em idempotência real, durabilidade e rastreabilidade.

Na Fase 3, passamos a ter uma garantia mais forte e durável de idempotência, baseada em uma Idempotency-Key enviada pelo cliente. Porém, toda requisição duplicada ainda precisava chegar ao banco de dados, o que poderia gerar pressão em cenários de alta concorrência.

Por fim, na Fase 4, combinamos o melhor das duas abordagens anteriores: Redis para lock rápido e temporário, banco de dados como fonte de verdade e Lua para liberar o lock com segurança.

Com isso, chegamos a uma solução mais madura, rastreável, performática e com garantia forte de idempotência.

Conclusão

Esse foi meu estudo arquitetural sobre idempotência aplicado a um webhook de pagamentos.

A principal lição que tirei desse processo é que cada solução traz impactos positivos e negativos para a aplicação.

No fim, cabe a nós, como desenvolvedores e arquitetos, entender os trade-offs, adaptar a solução ao contexto e combinar estratégias para extrair benefícios e mitigar limitações.

E, como quase tudo em arquitetura de software: depende do escopo, do risco e da criticidade da operação.

Muito obrigado por ler até aqui! ❤️

LinkedIn: https://www.linkedin.com/in/tarcisioaraujo7/

E-mail: tarcisio.olv@gmail.com

Também deixei o repositório com a implementação completa, testes automatizados para cada fase, ambiente Docker e pipeline de qualidade:

TarcisioAraujo7 / idempotent-webhook-study-case

Estudo de Arquitetura: Idempotência em Webhooks de Pagamento

Estudo de arquitetura backend em Laravel sobre idempotência aplicada a webhooks de pagamento.

O objetivo é demonstrar, de forma prática, como diferentes estratégias lidam com o mesmo problema: uma requisição de webhook pode chegar mais de uma vez e não deve gerar efeitos duplicados.

Escopo

Este projeto simula um endpoint de webhook de pagamento que despacha o processamento assíncrono de uma transferência bancária.

O estudo compara quatro abordagens:

sem proteção contra duplicidade;
deduplicação temporária com Redis;
idempotência durável com banco de dados;
estratégia híbrida usando Redis e banco.

Problema Estudado

Webhooks podem ser reenviados por timeout, falha de rede, retry automático ou concorrência entre entregas próximas.

Sem uma estratégia de idempotência, a mesma intenção de pagamento pode disparar múltiplos jobs, criar registros duplicados ou repetir operações custosas.

Stack

PHP 8.3+ (Docker e CI em PHP 8.4)
Laravel 13
MySQL 8.4
Redis 7…

View on GitHub

Conheça o recycle(♻️) do Laravel

Tarcisio Araújo — Wed, 05 Feb 2025 15:04:57 +0000

Quando o assunto é criar estruturas de dados complexas para testes, o Laravel oferece uma ferramenta extremamente poderosa que pode ajudar a economizar recursos e possibilitar a criação de ambientes específicos, garantindo maior assertividade nos testes.

Esta ferramenta é o método recycle(), ele oferece o poder de reutilizar instâncias de models em chamadas a Factories. Isso pode ser extremamente útil quando você precisa criar cenários com Models contendo relações em comum. Por exemplo:

// Cria um Time
$team = Team::factory()->create();

// Cria 3 Vendedores associando-os ao mesmo Time através do recycle
$sellers = Seller::factory(3)->recycle($team)->create();

No exemplo acima, criamos um cenário específico com 3 instâncias de Vendedores associadas ao mesmo Time. Dessa forma, é possível realizar testes com essa estrutura de dados definida, sem a necessidade de configurar manualmente as relações através dos atributos do create().

Utilizando Collections 🗂️

Além de funcionar com instâncias únicas de Models, o método recycle() também aceita Collections. No entanto, quando utilizado com uma Collection, seu comportamento difere do uso básico, oferecendo uma camada extra de flexibilidade na criação de cenários de teste.

$teams = Team::factory(3)->create();

$sellers = Seller::factory(30)->recycle($teams)->create();

Nesse trecho de código passamos uma Collection com três Times distintos no recycle. Desta forma, a cada Vendedor criado, será escolhido aleatoriamente um dos três Times para ser atribuído, construindo um ambiente controlado em que todos os Vendedores estão associados a um desses Times.

Como isso aumenta a performance do meu teste? 📈

Ao criar conjuntos de dados com uma grande quantidade de registros, reciclar instâncias irá poupar recursos e diminuir o número de inserções no banco de dados.

$sellers = Seller::factory(3)->create();

$sales = Sale::factory(500)->create();

Sem o uso do recycle, atingimos um total de 1003 queries! Sendo 3 para criar os primeiros Vendedores, 500 para criar cada Venda e mais 500 para inserir, individualmente, os Vendedores associados a cada Venda.

$sellers = Seller::factory(3)->create();

$sales = Sale::factory(500)->recycle($sellers)->create();

Agora, utilizando o recycle, conseguimos uma redução de 500 chamadas ao banco de dados! Eliminando as instâncias individuais de Vendedores realizadas pelas Factory de Venda.

Conclusão

Reutilizando instâncias de models, ele simplifica a criação de cenários complexos e reduz significativamente o número de queries realizadas. Resultando em testes mais rápidos, eficientes e fáceis de manter. O recycle() acaba mostrando-se uma ferramenta essencial no repertório de qualquer desenvolvedor Laravel, especialmente para quem trabalha com desenvolvimento orientado a testes.

Referência:

- Documentação oficial do Laravel.

Simples Mudanças, Grandes Impactos: Como Fortalecer a Segurança da Sua Aplicação Laravel

Tarcisio Araújo — Sun, 01 Sep 2024 14:10:22 +0000

Se você já trabalhou em algum projeto Laravel com certeza já ter percebido como o framework entrega uma vasta gama de ferramentas uteis para o desenvolvimento. Mas, você já se perguntou se não pode estar deixando passar algum erro? Se ao utilizar essas ferramentas não acabou escapando algum detalhe simples, mas importante para garantir a segurança do seu sistema?

Neste artigo irei mostrar alguns erros "simples", mas muito comuns e fáceis de serem resolvidos.

Fazendo um deploy seguro 🚀

Ao tornar um projeto público na internet é necessário se atentar ao arquivo .env que irá para os ambientes de produção/homologação, ou seja lá qual for o cenário de implantação, pois as chaves APP_ENV e APP_DEBUG podem estar abrindo possíveis vulnerabilidades nestes ambientes.

Qual a utilidade dessas chaves?

APP_ENV = Flag que irá indicar o ambiente atual da aplicação, ela pode receber valores como "local", "production", "staging", "testing", etc.
APP_DEBUG = Flag que irá indicar se o ambiente atual está em modo de debug, ela pode receber um booleano.

Use essa configuração apenas para ambiente de desenvolvimento.

APP_ENV=local
APP_DEBUG=true

Use essa configuração para ambiente de produção.

APP_ENV=production
APP_DEBUG=false

Qual o problema de não usar a configuração certa em produção?

Deixar uma aplicação Laravel no modo debug permite a exibição de mensagens de erros detalhadas, o que é ótimo para desenvolvimento mas, péssimo para outros ambientes, pois pode exibir as seguintes informações sensíveis:

Trechos de código.
Versão do PHP e do Laravel. (Pode ser utilizado para explorar falhas de segurança conhecidas das versões)
Informações do usuário e keys secretas.
Senha do banco de dados.
Estado da chave APP_ENV.

A chave indicando o ambiente estar com o valor "local" pode abrir um leque amplo de vulnerabilidades, que pode ir desde o Telescope, que fica aberto sem necessidade de login até o comportamento de alguma funcionalidade do sistema esteja utilizando o APP_ENV para determinar o fluxo. Como, por exemplo, a seguinte configuração para o consumo de uma api externa:

'api_service' => [
    'key' => env('APP_ENV') === 'production' ? env('API_KEY_PROD') : env('API_KEY_DEV')
]

Validando inputs 🔍

Todo desenvolvedor já deve ter escutado em algum momento da vida "Não confie no usuário" e neste artigo você irá ver mais um motivo para pensar assim.

Vamos imaginar o seguinte cenário, você possui em seu e-commerce um formulário de edição de produtos disponível apenas para os funcionários que não são gerentes, porém esse formulário não possui o campo valor disponível a fim de não permitir alterações por funcionários não autorizados.

Esta é a tabela produtos

id	valor	nome	quantidade	codigo	setor_id
1	100	Panela	4	PAN10323	3
...	...	...	...	...	...

Estas são as regras de validação do seu Form Request

public function rules(): array
{
    return [
        'nome' => 'string|max:255',
        'quantidade' => 'integer|min:0',
        'codigo' => 'string|max:255|unique:itens,codigo',
        'setor_id' => 'exists:setores,id',
    ];
}

E esta é a função utilizada no seu controller:

public function FuncionarioUpdateItem(UpdateItemRequest $request, $id)
{
    $item = Item::findOrFail($id);

    $result = $item->update($request->all());

    return response()->json(['sucesso' => $result], 200);
}

Você verificou e os dados foram atualizados corretamente, as validações foram bem-sucedidas e tudo parece estar em ordem. No entanto, há uma grande falha nesse fluxo: estamos considerando que o formulário enviará apenas quatro campos na requisição.

Mas o que acontece se um usuário mal-intencionado alterar manualmente o HTML da página para adicionar o campo valor? Ou se um invasor até mesmo enviar a requisição por meio de uma plataforma de API, como o Postman, incluindo o campo valor a requisição?

Digamos que o usuário malicioso enviou os seguintes dados para a rota:

{
   valor: 1,
   nome: 'Panela barata',
}

Você iria ter a sua tabela produtos com o seguinte registro:

id	valor	nome	quantidade	codigo	setor_id
1	1	Panela barata	4	PAN10323	3
...	...	...	...	...	...

Agora o produto que custava R$ 100 acabou disponível por R$ 1, e o problema está na forma de extrair os dados do request.

Errado ❌

$request->all();

Assim é retornado TODOS os dados do request.

Certo ✅

$request->validated();

Assim é retornado APENAS os dados validos do request.

Se o Controller do exemplo estivesse utilizando a forma correta de receber os dados, o mesmo exemplo de payload malicioso iria resultar no seguinte registro:

id	valor	nome	quantidade	codigo	setor_id
1	100	Panela barata	4	PAN10323	3
...	...	...	...	...	...

Evitando assim qualquer dado não esperado!

Evitando SQL Injection 💉

Quando falamos de SQL Injection falamos de vulnerabilidades que dão possibilidade para invasores executar comandos SQL indesejados e imprevistos no banco de dados da aplicação.

Exemplo:
Considere que seu sistema possui uma funcionalidade de pesquisa de usuários que executa a seguinte query.

$query = "SELECT * FROM users WHERE username = '$username'";

Considere que a variável $user é dada pelo usuário realizando a busca, se o usuário inserir admin'; DROP TABLE users; -- irá gerar a seguinte consulta.

SELECT * FROM users WHERE username = 'admin'; DROP TABLE users; --'

A consulta gerada é maliciosa e irá derrubar a tabela users inteira gerando um dano gigantesco a integridade da aplicação.

Como proteger minha aplicação?

Os próprios Eloquent ORM e o Query Builder do Laravel possuem uma proteção robusta contra inputs maliciosos e caracteres potencialmente perigosos para suas consultas. Porem devemos tomar cuidado ao utilizar quaisquer métodos que aceitem queries raw, pois estes se mal utilizados, podem resultar em aberturas para injeção de inputs mal-intencionados.

Exemplos:
Errado ❌

$email = $request->email;

DB::select("SELECT * FROM users WHERE email = '" . $email . "'");

Neste caso estamos passando diretamente o input do usuário para a consulta via concatenação de strings, que não irá realizar nenhuma sanitização de parâmetros.

Certo ✅

$email = $request->email;

User::where('email', $email)->get();

Desta forma utilizamos a proteção nativa do Laravel, passando o input como parâmetro da função que irá construir a query.

Certo ✅

$email = $request->email;

DB::select("SELECT * FROM users WHERE email = ?", [$mail]);

Supondo que você tenha realmente a necessidade de utilizar um método que aceite consulta raw, passe os parâmetros através de bindings. Desta forma, o Laravel irá impedir que o input seja interpretado como código SQL e manter a query segura.

Não se esqueça ⚠

Sempre use bindings quando o assunto for consultas com SQL bruto no Laravel.

Utilizando Rate Limit 🚧

Limitar quantas requisições podem ser realizadas em um determinado tempo é essencial para proteger a sua aplicação contra alguns tipos de ataques, como, por exemplo:

Brute Force: Tentativa de "adivinhar" senhas e credenciais realizando inúmeras requisições com combinações possíveis até obter sucesso.
DDoS: Tentativa de sobrecarregar o servidor com uma quantidade massiva de requisições em um curto período.

É recomendável considerar adicionar esta proteção em rotas relacionadas a formas de autenticação ou rotas com uso de token aleatório privado.

Como aplicar?

No arquivo AppServiceProvider.php você irá criar dentro da função boot o seu RateLimiter:

RateLimiter::for('default-limiter', function (Request $request) {
            return Limit::perMinute(10);
});

Pronto, agora com nosso limiter definido iremos aplicar a nossa rota sensível.

Route::middleware('throttle:default-limiter')->group(function () {
    Route::get('/private/{token}', [TokenController::class, 'privateThing']);
});

Considere que esta rota recebe um token gerado aleatoriamente para exibir um dado privado do seu portador. Desta forma estamos definindo um limite de 10 requisições por minuto, evitando um possível ataque por força bruta para adivinhar o token secreto e assim obter acesso à informação privada.

Ainda é possível definir regras específicas e personalizadas para a limitação como, por exemplo, por IP:

RateLimiter::for('default-limiter', function (Request $request) {
    return Limit::perMinute(10)->by($request->ip());
});

Essas limitações são usualmente baseadas em IP e no usuário logado, e são muito importantes para evitar diversos tipos de ataques, inclusive ataques DDoS feito com diversos IPs. Lembre-se sempre de criar regras de limitação robustas!

Se você já utiliza algum kit de autenticação pronto do Laravel como o Breeze ou o Jetstream então parabéns! Suas rotas de login já estão protegidas com Rate Limit.

Atenção ⚠

Preste bastante atenção ao definir as limitações para não afetar o uso normal dos usuários do seu sistema. Em casos de rotas com um fluxo maior de requests é recomendável utilizar o Per-Second Rate Limiting feature do Laravel 11.

Conclusão

Devemos manter sempre um olhar atento para questões de segurança durante o desenvolvimento, pois pequenas decisões ou deslizes aparentemente insignificantes podem resultar em grandes problemas no futuro.

Muito obrigado por ler até aqui! ❤

DEV Community: Tarcisio Araújo

Pagamentos idempotentes: Um Study Case de Arquitetura com Redis e Banco de Dados

O caso📋​

Como eu fiz 👷‍♂️​​

Fase 1️⃣​

Sem mecanismos para idempotência

Fase 2️⃣

Redis com hash de payload normalizado

Fase ​3️⃣

Fase 4️⃣

Resultados!

Conclusão

TarcisioAraujo7 / idempotent-webhook-study-case

Estudo de Arquitetura: Idempotência em Webhooks de Pagamento

Escopo

Problema Estudado

Stack

Conheça o recycle(♻️) do Laravel

Utilizando Collections 🗂️

Como isso aumenta a performance do meu teste? 📈

Conclusão

Referência:

Simples Mudanças, Grandes Impactos: Como Fortalecer a Segurança da Sua Aplicação Laravel

Fazendo um deploy seguro 🚀

Qual a utilidade dessas chaves?

Qual o problema de não usar a configuração certa em produção?

Validando inputs 🔍

Evitando SQL Injection 💉

Como proteger minha aplicação?

Não se esqueça ⚠

Utilizando Rate Limit 🚧

Como aplicar?

Atenção ⚠

Conclusão

O caso📋

Como eu fiz 👷‍♂️

Fase 1️⃣

Fase 3️⃣