Entrevista pleno: pedido, payment e Stripe na prática

Contexto do material

O ponto de partida do conteúdo é específico: Vou trazer um outro problema para vocês, quem já é dev um pouquinho. Olha só, imagina o seguinte, acompanha comigo, o usuário fez o pedido e tu bateu num serviço que é o serviço de payment.

Em vez de genérico, recorte a restrição real: Se comunica com a API do Stripe, tá? acompanha comigo aqui, então você fez o pedido, pedido bateu, fez uma requisição assíncrona aqui para o payment, para fazer a cobrança, depois o payment foi lá salvar os dados do pagamento dentro do banco de dados, estão acompanhando, o usuário fez o pedido, pedido bateu no serviço de payment, payment foi lá, se comunicou com o Stripe, falou olha, Pode gerar cobrança para o usuário.

Mudança operacional

O que muda no fluxo de trabalho: E ele falou, opa, Stripe devolveu 200 sucessos, vou salvar no banco de dados que deu certo. Então, essa mensagem que foi enviada aqui, ela vai ser tentada de novo daqui 2 segundos, 3 segundos.

Evidência do próprio material para ancorar a mudança: Então, ele vai lá, bate no payment de novo, o payment vai lá, conversa com o Stripe, fala, gera uma cobrança para o cliente. Porra, mas já tinha gerado uma cobrança antes, cara.

Armadilhas

Onde o time costuma se enganar neste tema: Só não tinha salvo no banco de dados, mas a cobrança já tinha sido gerada antes. Isso é se falhasse umas três, quatro, cinco, seis vezes.

Demo sem métrica, automação sem ownership e checklist copiado de outro contexto são as falhas mais comuns.

Para `entrevista-pleno-pedido-servico-payment`, pergunte: o usuário completa a tarefa sem você na call?

Próximos passos esta semana

Para aprofundar com links reais do ecossistema CrazyStack, comece pelo /blog, pratique com /curso-cursor-avancado-configuracoes-pro ou /curso-claude-code-9-dicas-profissionais, e se quiser formação completa use /programa-crazystack ou /checklist-independencia-cursor.

Ampliação a partir do material de origem

Vou trazer um outro problema para vocês, quem já é dev um pouquinho. Pergunta normal de entrevista de dev pleno. Olha só, imagina o seguinte, acompanha comigo, o usuário fez o pedido e tu bateu num serviço que é o serviço de payment. O que esse serviço de payment faz? Se comunica com a API do Stripe, tá? acompanha comigo aqui, então você fez o pedido, pedido bateu, fez uma requisição assíncrona aqui para o payment, para fazer a cobrança, depois o payment foi lá salvar os dados do pagamento dentro do banco de dados, estão acompanhando, o usuário fez o pedido, pedido bateu no serviço de payment, payment foi lá, se comunicou com o Stripe, falou olha, Pode

o cliente. Porra, mas já tinha gerado uma cobrança antes, cara. Só não tinha salvo no banco de dados, mas a cobrança já tinha sido gerada antes. Eu gerei duas cobranças. Ah não, agora deu certo. O banco de dados esno ar. E o cliente que se ferrou, né? Porque cobrou duas vezes. O falando sobre dead letter queue. Não é isso. Não é isso. Isso é se falhasse umas três, quatro, cinco, seis vezes. Tem gente acertando aí. O João, que eu vejo lá no Twitter também. O que é mais pleno já acertou. E dê potência, pessoal. O que é dê potência? Galera que é dev pleno aí, ó, entrevista, isso é uma das primeiras

que quando eu me comunicar lá com o Stripe da vida, eu falo para o Stripe, olha, esse aqui é o pagamento do pedido 01. Se esse pagamento do pedido 1 já foi feito antes, não é para ele reprocessar. Isso é uma coisa muito comum em microserviços, porque a partir do momento que a gente cria microserviços, a gente escriando aplicações que são toleráveis a falhas. Vão falhar. O meu serviço vai estar fora do ar. O meu banco de dados pode estar fora do ar. Elas podem falhar. E por isso eu preciso ter recursos para evitar que eu reprocesse a mesma coisa várias vezes. Então, em depontência... É a forma de evitar que uma operação seja

Como que eu implemento uma transação que depende de vários serviços ao mesmo tempo? Olha só. Vocês concordam que quando o usuário vai fazer um novo pedido, eu posso talvez ter um serviço de estoque que vai dizer se tem estoque ou não tem? Quando o usuário vai fazer um novo pedido, Talvez eu tenha um serviço aqui de análise de crédito, que eu verifico se esse usuário tem crédito, se ele tem nome, se o nome dele eslimpo para fazer esse pedido ou não. Então, quando o usuário vai fazer um novo pedido, eu tenho talvez um outro serviço aqui que eu tenho que consultar também na hora de fazer esse pedido. Então, o que acontece quando... Eu

é. E que vem essa ideia do pattern de saga, que ele é muito comum dentro. E para a galera que é das antigas do React, pessoal, isso aqui não tem nada a ver com o Redux Saga, graças a Deus, tá? Isso aqui eu não quero nem mais ver, nem pintar de ouro. O pattern de saga, ele basicamente diz o seguinte. Olha só, prestem atenção. Transações que contemplam múltiplos serviços transações, o que é transação? Um comando, uma requisição que contempla múltiplos serviços, devem ser quebradas em microtransações. O que isso quer dizer nesse caso aqui? Ao invés de eu ter uma única grande transação, pensa assim, que é criar pedido, eu divido isso em mais

exemplo, Stock Available, por exemplo, ou Unavailable. Esses eventos aqui, que vão ser ouvidos pelo nosso sistema de pedidos, Certo? Aqui já está, no caso, o nome dele. Não precisaria ter feito isso. E que vão alterar, por exemplo, o status do pedido para created, por exemplo. Então, antes, a gente tinha direto, a hora que o usuário criava um pedido, ele já ia como created, já estava pronto. Só, cara, e se não tivesse estoque? Se ele não tivesse crédito? Então, a hora que o usuário agora cria o pedido, ao invés de eu criar ele como status created, eu crio ele status pending, por exemplo. E eu sei que eu estou falando um monte de coisa para vocês,

Este artigo (`entrevista-pleno-pedido-servico-payment`) existe para converter material bruto em decisão. Se a sua restrição for diferente (caixa, time, stack), adapte o experimento — não o discurso. Continue explorando no /blog e use /programa-crazystack quando quiser trilha completa; para fluxo com IA no editor, /checklist-independencia-cursor e /curso-cursor-avancado-configuracoes-pro.