Essa noite aconteceu uma coisa muito chata. Em plena Black Friday, eu saí frustrado por 2 problemas de arquitetura encadeados. De um lado um banco digital que fica offline todo dia durante a madrugada e pior, inclusive na Black Friday.

Do outro, um e-commerce com o fluxo de pagamento síncrono, que perdeu uma venda de ~5k, porque não havia um fluxo de retry decente.

Mas temos pontos positivos! De outro lado, outro grande e-commerce lidou com o mesmo problema de forma diferente, dessa vez, pela natureza assíncrona, deu tudo certo.

De madrugada o pagamento falhou, mas agora pela manhã o banco autorizou e posteriormente o fluxo prosseguiu, como se nada de ruim houvesse acontecido…

É disso que eu tenho falado!

Contexto

Setup gamer para dev = ❤️

Espremendo ao máximo o início dessa história, em tudo começa por volta de 2012~2013 quando comprei um notebook gamer de um amigo. De cara um ASUS ROG, I7 topo de linha, 17 polegadas, 12gb de RAM, disco 7200RPM, placa de vídeo boa… enfim. Máquina incrível para uma época em que 4GB de RAM e I5 de entrada era o default. De lá pra cá me apaixonei pela linha gamer. E uso prioritariamente para desenvolver. O perfil de cliente da linha gamer é mais exigente¹, deu match comigo e desde então busco a linha gamer e tem dado certo.

¹ – Mais exigente, mais barulhento, e faz review: Isso exige mais das marcas.

De volta ao desktop

Em maio de 2017, eu resolvo fazer um upgrade e para um desktop gamer. Comprei o que havia de mais TOP até o dia da compra. I7 7700k de overclock, watercooler, GPU GTX 1080 TI, 32GB de RAM. Lindo exceto que… 15 dias depois a Intel lança o primeiro I9.

A natureza do que eu faço acaba exigindo máquinas melhores, primeiro pela edição de vídeo, segundo pela subida de aplicações com muitos componentes e muitos componentes de infraestrutura. Além de ser um mega entusiasta e gosto de não me frustrar com hardware.

Tá na hora de renovar…

Com uma máquina de 2017, ligada quase que ininterruptamente desde sua chegada, em 2019 eu comecei a me preocupar com a longevidade do setup. Em 2020 os preços dispararam antes que pudesse pensar sério nisso, deixando somente para 2021. Esperei o ano todo, namorando um novo setup que seria uma mescla de peças novas, peças antigas e coisas que comprei nesse meio tempo.

Pré-Black Friday 2021

Chegada a hora da Black Friday! 😬😬

Durante a semana eu dei uma pesquisada nos produtos, nas linhas, sabia que precisava de um conjunto de processador e placa mãe, talvez memória e GPU. Por fim resolvi deixar a GPU para depois, já que nunca havia conseguido chegar a 100% de consumo nela. A briga mental sobre AMD e Intel foi grande, mas pouca oferta de memórias DDR 5 para o 12900k me fez repensar e fazer um setup baseado no AMD Ryzen, com DDR 4.

Hora de revisar pesquisas de preço e minhas escolhas estavam contidas somente entre Pichau e Kabum e é aqui que vamos diferenciar o comportamento das duas aplicações. Quais aplicações? Os e-commerces!

Do lado de cá, como usuário, é possível entender diferenças no fluxo tecnológico, que afeta o fluxo de negócio, que por sua vez afeta o faturamento e inclusive o help desk e suporte.

Ou seja, cenários síncronos e assíncronos que demonstram como cada uma das plataformas funciona e por consequência como uma delas perde venda enquanto a outra converte! Ao mesmo tempo os impactos de negócio e no suporte ao cliente.

É sobre isso que vou detalhar aqui.

O cartão/banco digital… que dorme toda noite!

Na gestão dos meus cartões eu escolhi fazer essas compras no cartão que tivesse menor uso, um cartão que desse para fazer as compras, mas que não comprometesse o limite que costumo usar, portanto teria de ser um outro cartão que não o do dia-a-dia da empresa. E assim resolvi usar o PAN.

Uma característica curiosa do PAN é que toda madrugada o app do banco fica instável, como se eles parassem as API’s toda madrugada. Algo bem 2010 por sinal! Isso não ocorre as vezes, ocorre todo dia.

Mas com as campanhas de Black Friday, eu imaginei que pudesse ser diferente! Mas não foi. E pior, todas as compras nesse horário de indisponibilidade são recusadas. Descobri nessa madrugada!

A Black Friday

Como disse, eu tinha compras a serem realizadas tanto na Pichau quanto na Kabum. E usei o mesmo cartão em ambas. E é aí que vemos a diferença do comportamento síncrono do assíncrono pela perspectiva do cliente. Também vamos falar do retry….

A primeira compra aconteceu na Kabum. Por volta de 1 da manhã.

1:04 uma rotina em Perl envia um e-mail que chega 1:06 informando da realização do pedido.

1:07 possivelmente a mesma rotina em Perl envia um e-mail que chega 1 minuto depois informando que o banco não autorizou o pagamento. Também, no mesmo e-mail informa que tentará realizar o pagamento mais tarde.

O fato é que essa indisponibilidade do PAN fez com que todas as tentativas de compra fossem recusadas por qualquer plataforma. No caso da Kabum, eles tentariam depois.

Já na Pichau, foi diferente. Um dos produtos eu deveria comprar lá. Só que eu já estava esperando algum problema, pois eu me lembrava de ter visto a tela de aprovação do cartão logo no passo seguinte à finalização da compra, indicando que se tratava de um processo síncrono após o click que botão de finalizar compra.

Pela natureza síncrona, me foi dado o feedback de cartão recusado e só. Adeus pedido!

Retry que deu certo… 8 horas depois

De manhã, por volta de 9:30 recebo um e-mail da Kabum confirmando a compra.

Em resumo, enquanto a Pichau perdeu uma venda, a Kabum recuperou a venda com um retry de longa duração.

Isso não quer dizer que o processo ficou esperando para refazer, mas possivelmente entrou em uma fila de retentativa. No mínimo um controle via base é feito para isso, mas a forma mais inteligente é o uso de delay para entrega de mensagens em fila.

Com RabbitMQ seria relativamente fácil resolver esse problema com uma fila de dead letter que possua TTL definido em horas e que tenha como dead letter uma fila de reprocessamento. Pronto: Criado um mecanismo de retry com delay.

Ignorando esse assunto de RabbitMQ.

A diferença é que eu sou 1 cliente insatisfeito, que não conseguiu concluir uma compra de 5k.

Quanto de faturamento ficou na mesa por conta dessa decisão?

Será que a diferença de faturamento poderia ser suficiente para pagar as campanhas de ads e talvez uma parte substancial do tráfego pago?

Se mais 99 pessoas, com um ticket parecido com o meu, não conseguiram pagar na finalização do checkout e não tentaram comprar novamente, então teríamos 500 mil reais (meio milhão) não faturados.

Só 100 pessoas em uma noite.

Conclusão

Se fosse um projeto .NET, um simples retry com Polly não resolveria. Para conseguir realizar essa conversão (converter a tentativa de compra em venda) era necessário fazer um retry horas depois da primeira tentativa.

Ter ciência sobre os princípios de arquitetura que produzem falhas e saber como lidar com eles para produzir segurança, faria nunca o site da Pichau entrar em produção sem um fluxo assíncrono de pagamento e recuperação de vendas.

O PAN também demonstra total amadorismo ao ficar offline de madrugada.

E você, o que está fazendo para evitar esse tipo de coisa no seu projeto? Na sua empresa?

Eu peguei um exemplo real, no qual eu faço parte do processo e estou detalhando aqui. Eu fico realmente triste e P*** da vida com isso, porque eu vejo razões, motivos, argumentos para um possível fracasso quando eu vejo esse tipo de coisa.

Falhar por coisas novas, sob ideias que nunca foram testadas anteriormente: Ok!

Agora falhar por bobagens como essas, é ridículo!

Mas o que eu posso fazer a respeito disso?

Não tenho nada a fazer diretamente por nenhuma das instituições. Quanto à Pichau, eu refiz a compra com outro cartão, porque eu de coração queria comprar com eles.

Mas eu queria fazer algo mais!

Algo que pudesse ajudar você a não enfrentar esse tipo de cenário. Ou se esbarrar nele, conseguir fazer o follow up necessário para transformar cenários ruins em cenários positivos.

No final das contas estamos falando de gerar faturamento para nossos clientes, e do outro lado, de possibilitar que nossos clientes atendam mais clientes.

Por isso eu estou reabrindo a promoção de Black Friday que fiz no dia 11.

Meu planejamento era abrir as inscrições somente em Dezembro ou talvez somente em Janeiro. Mas a gente fez mudanças aqui dentro na turma que começou dia 11. A jornada de nivelamento, que se pauta em docker, saiu de 40 dias para ~ 22 dias. E com isso eu já consigo receber mais alunos nessa fase inicial.

Lembrando que a fase de docker é preparatório para os módulos de arquitetura, já que 100% do que fazemos é com base em containers.

As inscrições começam hoje, sexta-feira, na Black Friday e terminam quando acabar a Cyber Monday (de sexta, 26/11 à 23:59 do dia 29/11).

São ~1000 reais de desconto na compra do

Docker Definitivo + RabbitMQ para Aplicações .NET

Ou São ~500 reais de desconto na compra do Docker Definitivo

Ou São ~500 reais de desconto na compra do RabbitMQ para Aplicações .NET