Olá pessoal, tudo bem? Bem-vindos de volta à nossa jornada Cloud. Bom, até o presente momento nós falamos muito sobre AWS. Nós falamos muito sobre o que é esse mundo incrível da Amazon, como tem tantas features serverless que eu poderia usar sem configuração, pagando muito barato por isso. Então, nós falamos aqui de buckets, de lambdas, de ECS, de EC2, nós falamos de Fargate, nós falamos de EventBridge, nós falamos de SQS, SMS, nós falamos aqui de tantas outras, RDS, nós falamos de ElastCache, então nós entramos aqui com muitas features, né, pra podermos fazer projetinhos e mostrar como que as coisas acontecem dentro da AWS, então nós fizemos aí um modelinho muito no hands-on, mas você deve estar se perguntando e se eu precisar produtar de verdade, né como que eu convenço, como que eu demonstro uma arquitetura? A gente vai fazer aqui agora um projetinho de um marketplace. Eu quero poder comprar algo nesse marketplace e eu quero poder visualizar a entrega disso e eu quero poder avaliar essa entrega depois. Então, como que eu posso produtar isso pensando na WLS? É um pouco brincar de lego. É pegar as pecinhas e encaixar. Claro, a gente tem pormenores. Em cada uma dessas pecinhas, a gente pode ir colocando um outro item ali, para trazer mais e mais especificidade para os nossos itens. Mas aqui nós vamos fazer um blueprint. Pensando dessa forma da nossa plataforma de marketplace que a gente está sugerindo aqui. Então, vamos ver como eu produtaria isso na AWS. Como eu levo para um time de desenvolvimento um desenho pronto. E já pensando na arquitetura cloud. Já pensando em um uso dessas features aqui então vamos lá eu vou desenvolver o back-end disso ok eu não vou tratar aqui com front-end eu vou colocar aqui um API gateway porque eu tenho uma API back-end eu preciso então de um API gateway eu não vou descrever as rotas aqui eu teria a rota de solicitação do pedido de acompanhamento do pedido vamos fazer algumas frentes aqui vamos fazer a primeira frente para a solicitação desse pedido ok então vamos lá a paygater só que esse a paygater ele não mora sozinho ele precisa de um autorizador, aqui eu não estou falando ainda da autenticação do cliente, tá? Estou pensando aqui na autenticação da aplicação, tá bom? Então aqui esse Lambda Authorizer, eu poderia ter a partir dele aqui, aqui, um STS aqui, um gerenciamento de credenciais por tempo, num protocolo OAuth 2, por exemplo, então tenho essa Lambda aqui, Lambda Authorizer, Gate, vou colocar aqui um aplicativo vamos colocar aqui o celular o aplicativo, só para a gente falar que esse carinha tem determinada origem, vamos lá vamos dizer que eu estou aqui, celular celularzinho, aplicativo está processando aqui bom a partir do momento que eu estou aqui, celular, celularzinho aplicativo, está processando aqui. Bom, a partir do momento que eu tenho um gateway aqui dentro, eu vou partir de que eu tenho uma volumetria muito alta. Eu poderia colocar uma lambda para esse gateway. Mas se eu tiver com essa lambda, sei lá, da minha VPC, a partir de determinada concorrência, se eu tiver aí numa Black Friday, né? Vamos colocar esse exemplo aqui. Eu vou ter muito acesso. Então, eu posso dependendo da linguagem da Lambda, da quantidade de memória, do tanto de execuções simultâneas que eu tiver, eu posso ou bater o teto de execuções simultâneas da AWS de jeito alto ou se eu estiver com essa Lambda na minha VPC ela vai escalar tanto que vai começar a sequestrar IP vai começar a dar problema de trocling na minha rede então eu não vou usar essa Lambda eu vou usar um recurso tão interessante quanto eu vou usar um balançador vou jogar aqui um load balancer, vou colocar para o queixo, load balancer clássico vou jogar um load balancer aqui, um MLB, vou ter aqui um MLB na minha aplicação. Então, o meu Gator vai lançar aqui sua requisição para este balanceador. O balanceador me faz tanto ida quanto volta, porque eu estou em um protocolo HTTP, então eu tenho uma exigência de resposta. A resposta é junto, é malta. Então, ele vai e volta aqui para mim, para o meu gateway. Então até este momento, o que está acontecendo? Meu cliente acessa o aplicativo, clica lá no comprar, por exemplo, ele está navegando, clicou no comprar, ele vai vir aqui, a aplicação vai validar se esse aplicativo pode passar se não puder passar nunca vai chegar aqui se ele puder passar se ele tem um token válido tem um token válido ele vai continuar para o balanceador. Dentro do balanceador, primeira coisa que eu vou precisar fazer, tá bom? É pegar aqui e colocar um ECS. Vou colocar um ECS aqui. Vou falar que eu tenho um ECS, um Amazon ECS aqui. Então esse balanceador vai falar com meu ECS, deixa eu pegar aqui um quadradinho para a gente guardar esses resultados, então o ECS ele tem alguns containers, eu vou colocar aqui no ECS com um grupo de auto scale, então eu vou colocar aqui que é um ECS, eu vou pegar aqui um container, por exemplo, vou representar, vou usar essa figura, vou fazer um agrupamento para representar minhas aplicações ECS vou colocar aqui, vou deixar como cópia, porque talvez eu vá usar esse mesmo desenho em algum momento nessa mesma arquitetura vou jogar aqui embaixo mesmo meu NLB vai buscar aqui uma testes que necessita ela vai pesquisar o serviço está rodando dentro dela tem algumas regras a primeira coisa ele vai validar esse usuário então vou colocar que ele vai chamar uma outra aplicação e vai validar o usuário esse daqui seria o meu orquestrador vou chamar ele de orquestrador neste momento tá bom então esse orquestrador aqui vou colocar? topo, não deixa eu ver o direito não é, não está pegando aqui meu texto não, meu texto não está querendo brincar não agora está certo, vamos lá então, aqui agora eu tenho um orquestrador e eu tenho uma clientes aqui agora eu tenho um orquestrador e eu tenho uma cliente cliente aqui não gostei de onde se eu consigo resolver um pouco melhor esse texto. Esse orquestrador que eu tenho aqui, ele está num grupo de outscaling, então ele vai escalar. Aqui ele vai consultar o serviço de cliente ele vai ter um acesso aqui dentro do serviço de cliente aqui dentro ele vai via nlb também porque serviço de cliente pode estar sendo acessado por um outro gateway, inclusive vai. Então eu posso dentro da AWS, não preciso passar pelo gateway, eu posso passar pelo balanceador, vou invocar esse balanceador a partirquestra pedidos, tenho uma API que valida cliente. Essa API que valida cliente, ele tem um RDS aqui com ele. Tá bom? Então, eu vou jogar aqui um RDS. Aqui o meu RDS, aqui meu RDS, esse meu RDS aqui, ele é um POST, se eu falar que ele é um POST, post-its ele tem aqui uma integração com a base de dados ok? então nessa integração com base de dados ele é um cadastro de cliente eu vou copiar essa configuração aqui porque em outro determinado momento o meu gateway passa a falar também com o balanceador da aplicação de clientes. Então estou pensando que aqui estou fechando o pedido e aqui eu estou cadastrando o cliente. Olha como os fluxos começam a tomar formas aqui dentro. Eu poderia separar isso aqui. Estou tentando montar uma macrovisão para vocês. Então eu tenho aqui um orquestrador, tenho aqui uma peita de clientes, perfeitamente os caminhos que eles estão seguindo aqui dentro da minha conta da WS então aqui ele tem uma pay de clientes uma RDS de clientes tá qual a responsabilidade desse carinha aqui validar senha validar cadastro atualizar cadastro né esse RDS aqui ele pode estar num Read Replicas, tá ok? Ele está num Read Replicas, tá? Então, é basicamente isso. Então, ele buscou aqui, validou a aplicação de clientes, ok? Viu aqui que meus clientes estão tudo certinho. Vou seguir, então, com o pedido dele, certo? A partir deste momento, ele já dá uma resposta para o canal. Falando, ó. Cliente está ok. Então, eu poderia estar com isso aqui. Vamos pensar que eu tenho mais uma aplicação para ele orquestrar. Ele precisa orquestrar uma aplicação de produtos. Então, vamos lá. Ele tem também uma API de produtos. Essa API de produtos também tem o seu balanceador. Olha só. Meu orquestrador agora vem aqui para o balanciador da API de produtos ok vamos lá tá aqui na API de produtos a API de produtos recebe esse item do balanceador aqui também de volta olha orquestrou cliente existe ok produto existe ok fazendo uma idéia mais macro tá bom essa API de produtos gente ela tem que responder muito rápido tá bom como isso aqui também tem que responder rápido mas aqui é uma base mais relacional do antigo uma base de RDS pra ele a minha API de produto produto ele pode ter muita foto pode ter muita coisa né eu vou falar esse cara e ele tem um produto também não sofre muito alteração você muito mais um preço e eu vou falar que os meus produtos ou estar armazenado sem o bairro meus produtos vão estar armazenados em um DynamoDB. Vou mexer muito no produto. Ele é mais cadastral e pesquisa. Então, esse carinha aqui está em um DynamoDB. Só que, o produto também tem muitas imagens. Qual é o melhor lugar para guardar essas imagens, né? Também tem muitas imagens. Qual é o melhor lugar para eu guardar essas imagens na AWS? Vou jogar no bucket S3. Vou jogar aqui um bucket de imagens de produtos. Vou jogar aqui um bucket de imagens de produtos, vou jogar aqui um bucket de imagens de produtos, tá bom? E aqui, este carinha é capaz de devolver a URL dessas imagens, eu torno elas públicas, pego as URLs delas, passo como objetos para serem acessíveis aí, tá bom pelo nosso é pela nossa aplicação também tenho então se eu tenho um balanceador eu vou ter também um gateway para produto que que é esse gateway aqui isso aqui é estou cadastrando dentro de produtos. Ah, eu tenho que ter um gateway para cada item? Não necessariamente, mas é importante você segregar responsabilidades, tá bom? Depois a gente joga os cachinhos aqui para você entender. Para você ter responsabilidades divididas. Cada um está com sua base de dados, cada um está com o seu próprio domínio de responsabilidade. O meu STS aqui, minha Lambda Autoral, está validando as chaves de aplicação, ele está buscando. Então, pus no carrinho, cliquei no OK. Mandei aqui, validei. Cliente está certinho pus no carrinho cliquei no ok mandei aqui validei cliente está certinho sempre certinho orquestrei aqui produto está certinho eu tenho até as imagens do produto aqui para colocar isso fechar um pedido né depois isso aqui então o que eu vou fazer? Eu vou fechar um. Tenho cliente, tenho produto. Eu vou agora fazer um sistema que eu já tenho o suficiente para seguir. Ou seja, eu não preciso deixar esse cara esperando mais. Porque eu validei cliente, validei produto. Produto existe. cliente, validei produto, produto existe, e esse cadastro de produto aqui, ele tem uma integração com uma segunda PIN, e a minha, o próprio produto tem aqui, tá? Vou colocar aqui, note que eu não estou fazendo muito uso de lambda, porque a nossa premissa é não ter troco, é que eu vou aguentar milhões de requisições, então a instalabilidade aqui é melhor, eu posso fazer mais uso de memória, aqui eu posso trabalhar com paralelismos, muito melhor a depender da linguagem, tá bom? Então aqui eu vou apenas separar por aplicação um controle de estoque. Então, o produto vai falar, produto existe? Existe. Mas existe um estoque? Note que essas bases aqui, elas se sincronizam. Vamos deixar aqui uma base de estoque. Esse estoque, ele vai receber um evento depois de pedidos. Vou subir isso aqui. Tá bom? Ele não tem acesso direto. Vou precisar de um balanceador aqui, vou precisar de um balanceador, aqui um balançador de volta e de volta com o controle de estoque vou estender essa base de dados aqui pro lado pra gente manter aqui isso aqui é o cadastro de produtos e agora produto mantém aqui em estoque vai ser também um daemon não, ele sofre muita atualização então se eu tenho muita atualização talvez uma base no SQL não seja a melhor talvez eu possa controlar isso por um rds aqui um pouso está muito a atualização então eu tenho um controle de estoque aqui um controle de estoque, ok? Vou manter aqui um controle de estoque. Se tem uma NLB, então eu vou por um gateway aqui, porque eu admiro o sistema, quero que esse controle de estoque exista pra mim, então eu vou fazer fazer isso note que essas aplicações estão integradas a partir do estoque do cadastro de estoque eu posso cadastrar um novo produto, por exemplo pensa no front que isso aqui são etapas diferentes ali no cadastro de produto eu estou segregando o produto para um lado, estou segregando o estoque disso para o outro exatamente porque aqui eu tenho uma responsabilidade muito mais runtime. Então, a consulta do produto é mais no fator da existência desse produto, de eu ter ele lá, de eu disponibilizar, de eu poder mostrar as fotinhas e tudo certinho. E aqui é um cara que vai mais controlar o estoque e do pedido. Uma vez que eu orquestrei aqui, cliente e orquestrei os produtos, validei, uma vez que eu vim aqui, meu produto veio. O produto existe? Existe estoque? Ele existe na tabela. Existe um produto viável? Existe estoque? Tá. Aqui eu já poderia responder. Se não tivesse estoque, jáaria pra ele não tem estoque meu amiguinho, desculpa, não dá pra seguir o seu pedido isso aqui tem que ser muito rápido, dois segundinhos, respondi pro canal o canal falou, tá bom, beleza agora eu vou seguir com o meu pedido, o cliente já fechou o pedido dele mas agora falta uma coisinha, vou colocar um um SQS aqui a partir do momento que ele orquestrou eu vou chamar de SQS pedidos Vou chamar aqui de SQS de pedidos. Então o que eu vou fazer aqui com o SQS de pedidos? Vou firmar o pedido. O que eu vou passar no SQS? Vou passar o cliente, vou passar o produto e vou passar a quantidade. E consequentemente eu vou passar o valor. Vou jogar aqui na SQS de pedidos. Que legal! Agora eu vou ter uma outra aplicação também tem o seu próprio grupo de Scaling que lê esse SQS ele lê esse carinha aqui vou falar que ele é o meu pedido ok gente, pedido não tem muita atualização correto? não tem então uma vez que ele não tem muita atualização eu vou colocar um dynamo nele minha base de pedidos vou jogar aqui o Dynon pedidos. Aqui para ficar diferente vou falar que é é o IDS Postgres Stock e aqui é o IDS Postgres Client. Eu gosto do Postgres pessoal pela robustez, ok? Não que o MySync ou o MariaDB não conseguem atender nisso, tá? É que eu entendo o Postgres com um pouco mais de robustez em tamanho, de tabela, em tudo ali dentro. Eu acho que ele tem muitas features legais para esses sistemas de larga escala, então é o que eu costumo indicar quando eu tenho esse tipo de sistema. Quando eu estou falando um pouco mais de controle de usuário, pensando aí no blog, no WordPress, MySQL atende muito melhor esses lados. Não que ele não possa atender muito bem outras coisas, mas eu entendo que ele tem um perfil muito mais para o web, para o dia a dia, do que para esses sistemas mais robustos. É uma preferência talvez pessoal, acho que muitos arquitetos concordam. Tem alguns comparativos que mostram o quanto ele pode ser um pouco mais robusto. Mas acho que é legal vocês darem uma olhada nisso também em algum momento. Está aqui. O dinamo de pedir. Peguei. Gravei o pedido. Esse cara aqui, eu quero só que ele orquestre., não quero que ele tenha responsabilidade sobre base nenhuma. Ele coloca aqui no meu SPS, meu pedido grava em pedido e o pedido ele tem que fazer uma coisinha, tá bom? meu sentido agora eu vou colocar olha que legal acho que aqui vai ser bacana eu poderia fazer um dynamo stream mas aí eu pra poder fazer o dynamo stream o mais fácil seria colocar uma lambda né mas eu não quero colocar essa lambda aqui porque se eu coloco essa lambda aí eu posso em uma black friday voltar, tem um sistema de trolling né então eu tô fazendo uma arquitetura mais baseada ali no E se eu tenho um pedido aqui, eu também vou ter uma API, vamos lá. Também ter uma API Gateway para esse carinha. Porque o cliente pode consultar os pedidos dele, correto? Pode até cancelar um pedido. Então, Gateway. Pode até cancelar o pedido. Então, gaiter, balancer. Vamos lá. Gaiter, balancer. Perfeito. Uma vez que o gaiter funcionou vamos lá o meu cliente claramente entendendo como o sistema vai começando com uma forma? Vai começando a virar aquele desenho de placa-mãe. Não é tão saudável você fazer tudo em um lugar só. Você poderia falar, olha, esse aqui é o meu orquestrador. Guardar esse pedaço em uma caixa. Olha, esse aqui é a parte do pedido. Essa daqui é a parte... Você pode colocar colocar assim a gente teria mais visibilidade mas não impede também de você seguir assim um pouco, desde que você vá pontuando os passos, pode pegar aqui uma caixinha de texto colocando do lado sabe, os textos, explicando o que é cada coisa, que passo que ele está fazendo muito saudável isso também tá bom? então vamos lá pedido meu pedido ele recebe aqui solicitação de pedido grava em base cliente pode posteriormente vir aqui consultar, cancelar, fazer alguma coisa disso. Para cada alteração que eu tiver, tanto pela fronteira do SQS, como pela fronteira, eu vou ter aqui uma, duas filas que eu vou criar. Tá bom? Vou criar dessa forma, vou colocar aqui esse SQS, vou chamar de SQS de cobrança. SQS de estorno, eu vou chamar SQS de cobrança. Os dois vão ter a competição. Então, eu vou manter aqui um SQS, eu vou manter aqui um SQS. Tá bom? Vocês lembram de uma coisa? Que o SQS não tem indepotência, né? Então, aqui, o que eu posso fazer aqui para resolver esse problema? Duas coisas. Eu posso ter um SQS FIFI e colocar uma ID de desduplicação, essa é uma forma de ver, tá bom? Um SQS FIFI, uma ID de desduplicação, ou eu posso montar uma máquina de estado no leitor. É uma forma da gente também analisar isso. Porque essa revistagem, embora ela não garanta a hipotência, ela também não tem uma frequência de repetição muito grande, não tem garantia dessa repetição, ele não tem a garantia da hipotência. Então, pode repetir? Pode, pode ser que não repita também lembrando que se eu colocar aqui uma fila FIFO, eu tenho um throughput muito menor um throughput muito menor do que uma FPS default, então o que eu vou fazer aqui pessoal, eu vou fazer aqui pessoal eu vou criar aqui um EPCS esse EPCS eu vou chamar de financeiro que não sei claro que aqui eu teria muitos outros conceitos ele vai receber aqui tanto o estorno como ele vai receber aqui a cobrança vamos pensar o seguinte se o cliente veio aqui e fez o pedido o pedido cadastra e ele tem inteligência para falar cobra. Se o cliente veio aqui, pegou um pedido e falou cancela, esse carinha aqui tem a inteligência para falar estorna. Mas ele não conhece estorno, ele não conhece cobrança. não é responsabilidade do pedido com isso é isso é responsabilidade do financeiro bom então ele atende duas filas que ele lê carinho que tem a responsabilidade de ligar com isso vou por exemplo paypal esse cara aqui faz fronteira com paypal então eu posso chegar aqui ó não sei a fronteira que provavelmente o pt web vou declarar aqui que não é NAT gateway ele é um router, vou deixar aqui como se fosse um routerzinho aonde essa aplicação vai até ele para poder chegar na web então ele tem esse gerenciamento sobre os itens de cobrança o financeiro faz isso aqui pra gente feito então ele sabe estornar e ele sabe cobrar. Então eu vou colocar aqui uma terceira fila. Porque se esse cara tem capacidade de enviar, ele tem que ter a capacidade não só de enviar mas de retornar aqui eu vou fazer uma fila só vou fazer um retorno de estorno. E vou fazer um esquece de retorno de cobrança. Como eu estou separando em duas filas, para ficar semanticamente mais claro. Tá ok? Então, aqui está. Opa! Esse carinha aqui tem capacidade de produzir informações aqui dentro. Vamos jogar ele mais para lá. Aqui tem uma hora que é tão chatinho, né? Essa setinha. E você vai mexer nela, ela não trava. Tem uma hora que ela fica tão chata. Vamos lá. Vamos escolher uma reta. Ele precisa fazer uma determinada coisa. Vamos pensar em como deixar isso aqui mais legal. Agora ficou legal. Agora eu vou pegar mais um desse aqui. E ele tem isso aqui também. Então, é isso. É isso. Esse cara produz aqui. E esse bebe tanto dessa fonte. Como também bebe. Dessa fonte. Olha que legal. Agora eu tenho uma responsabilidade bem mais clara para o meu pedido. Então, revendo aqui, fez a cobrança. Se o financeiro deu certo, vamos dizer que ele não conseguiu cobrar. O que ele vai fazer? Ele já vai retornar na cobrança falando não deu. Se ele conseguiu, ele já vai retornar na cobrança falando deu. Entendeu que agora é manutenção. A responsabilidade de lidar com o pedido está aqui. Esse cara sabe qual produto é ele sabe qual é o e dedo do produto se ele precisar redirecionar que devolver o produto para que esse carinha entre por esse gay para entender os produtos que ele comprou ele consegue então temos aqui uma arquitetura de pedido, uma arquitetura do financeiro, tem o produto, o estoque. Uma coisa aqui, ele não tem que saber só cobrar. Uma vez que ele recebeu a cobrança, ok, esse cara tem que, pelo estoque aqui ó, vou por uma outra fila, tá bom? Note gente que tudo eu estou atrelando a base de dados, né? Tudo eu estou atrelando a base de dados aqui. Então se eu estou atrelando isso nessa base de dados, ele não vai repetir, ele sempre na aplicação vai olhar se aquilo já aconteceu em base. Como ele está apartado, isso é muito mais fácil. Aqui eu vou ter que colocar um outro item aqui no financeiro. Mas vamos pensar o seguinte aqui. Eu vou colocar um SQS no pedido e o pedido vai, uma vez que eu cobrei, ele vai atualizar o estoque. Ele vai chegar aqui e vai falar, ó, cobrança deu certo. Agora eu atualizo o estoque. Cobrança deu certo, eu vou lá e vou atualizar o estoque daquele produto. Por quê? Porque eu conheço o produto que eu tenho pedido. Aqui eu vou colocar uma base Dynamo e vou falar que ele é o Dynamo de cobrança financeira. Então, aqui, Dynamo Financeiro, essa aplicaçãozinha aqui, ela tem essa impelidícia, e você pode notar que ele não tem a pênis, se eu precisar conhecer, eu conheço tudo a partir do pedido, o pedido que conhece essas itens, ele vai e volta, né, é um movimento assíncrono, eu conheço tudo a partir do pedido, o pedido que conhece essas vítimas, ele vai e volta, é um movimento assíncrono, eu não vou expor esse cara, não ter um risco de exposição sobre ele, mas eu posso objetivamente fazer uma API interna para consultar isso. Não acho agora, não vou explorar essa possibilidade, mas eu poderia, tá bom? No momento eu já tenho essa visibilidade aqui, né? Qual é a diferença do cliente acessando esse gateway para eu, o sistema acessando esse gateway? É a permissão, tá bom? Então, poderia ter uma empresa de gerenciamento olhando para isso, com perfis diferentes, né? Não vamos explorar muito esse pedaço, apenas para a gente ver aqui fiz o financeiro, cobrei financeiro agora manda para a logística fazer um sistema de logística fazer aqui vamos manter ele aqui dentro. Eu vou falar que esse aqui é o meu ECS de logística. esse de logística ele vai saber o seguinte agora eu preciso entregar ó eu preciso entregar ele sabe quem é o cliente ok então ele vai vir aqui no gateway do cliente aqui no gateway do cliente, note que ele está acessando aquele gateway lá em cima para fazer essa nomeação aqui para a gente saber o que a gente está acessando cliente então ele vai aqui ele tem um SQS esse Dynamo aqui pessoal quando se caso acontecer um problema aqui dentro, na hora que chegar aqui um pedido de estorno, eu verifico para esse pedido o estorno já foi solicitado para essa cobrança já foi solicitada se eu não cobro duas vezes no estorno duas vezes, eu tenho depotência garantida pela aplicação. A aplicação torna-se depotente. Então, vamos lá. Uma vez que eu não posso receber a mesma mensagem duas vezes ao mesmo tempo, porque ela fica em trânsito, né? Então, isso já resolve bastante coisa para a gente. Vou fazer aqui, SQS, SQS logística, pra mandar pra entrega. manda pra ele é essa aplicação led essa aplicação tem um daílamo aqui esse carinha da logística ele também vai ter uma fronteira forte aqui é o gator de pedidos com pedidos porque tem uma questão aqui que é o tracking desse pedido então eu tenho aqui dentro um gator de pedidos. Então eu vou também colocar aqui. Por quê? Porque neste momento ele vai fazer uma atualização no pedido aqui e vai falar. Está andando, não está andando. Como já tem um gateway aqui, verdade, gateway não, gente. Eu estou na mesma conta. É o gateway, mas não é ele diretamente. Na verdade, o que eu invoco aqui é o MLB. É o que está por trás dele né é o que está por trás dele aqui então eu vou pegar aqui vou pegar esse nlbzinho e vou falar que esse aqui é NLD, NLD pedidos, vou chamar de NLD pedidos, vou até jogar a linha ele aqui, para a gente poder diferenciar, NLD pedidos, esse daqui é o NLD de produto, NLD de pedidos, esse daqui é o NLD de produto. Muito bom a gente ir nomeando, não podemos esquecer. NLD de clientes. Então, vamos lá. Ele chama aqui o NLD de pedidos para poder atualizar o estado do pedido o que mais ele precisa atualizar o nlb de pedidos pedidos vai guardar aqui no Dynamo dele na base na tabelinha de logística qual é o pedido, se deu certo vai atualizando o que mais ele vai precisar fazer ele pode também fazer uma notificação vou criar um serviço de notificação colocar ele apartadinho vou pensar que estou usando aqui uma sms para fazer push para o cliente para mandar e-mail né usando aqui vou deixar só como sms porque ele é de fato só um serviço de notificação. Vou mandar aqui para um SNS. Aqui eu teria toda uma distribuição sobre isso. E vou mandar aqui um SQS para esse nosso cliente. Na verdade, essa fronteira não é essa. Essa fronteira não é aqui, essa fronteira é aqui esse cara pega do SQS, esse cara aqui bem legal, ele tem a inteligência de falar a notificação, ele coloca aqui a notificação e esse app aqui faz a notificação para o cliente. Por que eu estou separando isso? Porque eu poderia ter outros pontos de notificação lá em cima, se eu quiser alterar, vou mandar um push, parabéns, você alterou seu cadastro, parabéns, você alterou seu pagamento, então vou colocar uma pi vou colocar no mesmo modelinho aqui aonde ele sai vamos só ele sai por aqui e aqui ele vai para a transportadora não tem nenhum ícone de transportadora, tem sim, tecnologia de transporte tá bom olha que legal ele envia aqui pra nossa transportadora olha que bacana que tá aqui representada por esse aviãozinho certo? então vamos ver aqui o que que acontece ó enviado pra transporte todo o treino está fazendo acidente pedido tem o seu treino e tem um acompanhamento ele vem de status disso aqui não quer apresentar uma única tabela posso ter duas tabelas da anomalia no mesmo serviço tá bom pensando que uma de pedidos outra treino impedidos tá bom coisas mais ou menos desse tipo. Então, se eu fosse falar com você, olha aqui um produtinho feito dentro da AWS, claro, novamente, pessoal, aqui, ele está no modelo muito mais de comunicação robusta, ele não está separado, eu poderia criar várias páginas minhas e começar a separar, colocar aqui umas caixas falando, olha, esse carinha aqui começa como? Está no carrinho, estou pensando já no checkout disso, está no carrinho, mandou para o registrador, validou a credencial da aplicação, veio no cliente, validou o cliente, veio no cliente validou o cliente veio no produto validou o produto veio no estoque validou o estoque lembrando cada um dos itens dessa saga que tem seus próprios modelos de erro validou o estoque devolveu para o cliente e falou, beleza, seu pedido está comigo, eu sei quem você é, eu conheço seus modelos de pagamento, eu conheço o produto, aguarde aí que eu vou dar seguimento aqui. Continuando com o pedido, ele entra aqui em pedido, firma o pedido, valida tudo o que ele precisa. E vai fazer o que? Vai orquestrar. Gravei o pedido. Vou enviar para a cobrança. Vamos fazer o caminho legal. Foi para a cobrança. Tentei cobrar. Deu errado. Devolve. Atualiza o pedido. Olha um reuso bacana aqui agora, SQS notificação, olha aqui que legal, olha o que a gente já pode fazer, SQS notificação, vou colocar Vou colocar esse SPS ali em cima. E olha aqui. Concorda comigo? No momento em que ele recebeu esse pedido, falou que não conseguiu cobrar, eu já posso aqui notificar o cliente falando desse cliente o seguinte. Falando, olha, não consegui te cobrar. E só de eu apontar para o SPS notific olha, não consegui te cobrar. E só deu apontar para esquece notificação, quem está lendo ele aqui. A gente já sabe, eu poderia fazer uma linhagem, colocar um texto, colocar um número aqui do lado. A integração a ser observada no item número blá, blá, blá, blá, blá. Coloca o texto lá e coloca o item aqui bem grandinho do lado para a gente encontrar. Tá bom o primeiro lá lá lá lá lá lá lá lá lá lá lá lá lá lá lá lá lá lá lá lá lá lá lá lá lá lá lá lá lá tá bom olha aí envia para notificação não como se mandei aqui conseguir cobrar consegui então eu mando para logística essa base de logística é de financeiro aqui e renomear olha só e essa base de logística guarda aqui para quem foi enviado quando foi dado como tá acontecendo e comunica tudo com pedidos tá bom porque porque esse carinho aqui, vamos precisar colocar também nele, para poder ficar bem certinho um NLB vamos precisar colocar um balanço deixa eu pegar aqui NLB logística e um NLB logística também por que isso? porque a transportadora ela pode efetivamente falar que não achou o cliente alguma coisa assim do tipo, não é mesmo? Então, esse carinha aqui também está aqui, esse carinha está aqui, nosso aviãozinho aqui representado pela nossa logística está aqui do lado também, porque ele pode fazer requisições do lado de cá. Aqui o caminho da TTP, vai e volta. Foi e voltou. Então, se ele tiver algum problema aqui, ele já notifica o pedido. Ah, não consegui entregar o cliente. Notifica pedido. Pedido faz expor. Olha só que legal. Está vendo como uma coisa começa a entrar na outra? Cada um com sua responsabilidade. Notifiquei o cliente. Consegui entregar. Legal. Ele vai e entra aqui. Notifica pedido. Certo? Pedido vai chegar aqui. Vai lá. Legal. Seu negócio, seu produto chegou. Olha aí que legal. Dá uma nota para a gente. negócio o produto chegou olha aí que legal dá uma nota pra gente também o que o cliente pediu estou a sua história mandou estou no ok aqui vamos dizer que eu não consegui fazer o estorno da operação não deu certo fazer esse torno aqui não daria para uma fila de incidente, mandaria alguma coisa para a gente poder analisar, e aí seriam ações que o time de produto da minha empresa teria que tomar conta disso. Mas olha só, cada caixinha aqui, com sua determinada responsabilidade, é um sisteminha que faz uma trilha de checkout, não é todo marketplace, mas faz uma trilha de checkout. Então, todo o marketplace mas faz uma trilha de check out então eu poderia separar aqui como eu falei ó uma caixinha aqui pra cada um desses carinhas exemplificando isso aqui é muito do blueprint da plataforma faltou aqui uns comentários a gente pode colocar uns comentários pode colocar números eu gosto de usar o draw.io para fazer esses diagramas, tá bom? Porque ele tem muita ferramenta, principalmente os itens da AWS. E olha só, isso aqui é uma arquitetura que não ficaria cara, tá bom? Por quê? Porque esse quadradinho aqui, ele representa o grupo de autoespelho. Então, eu vou pagar mais se ele escalar mais. Se eu não estou tendo muita requisição, obviamente eu posso pôr embaixo. E uma coisa legal também, gente, nota que esses serviços aqui, sabe, alguns serviços aqui, que não tiver fronteira com gateway, por exemplo, esse item aqui de notificação, ele não tem fronteira com o gateway. Eu vou estar fazendo notificação a todo momento, quais são meus cenários de notificação? Pedido cancelado, pedido entregue, né? Coisas mais esporádicas ali que não vão acontecer o tempo inteiro. Eu posso colocar aqui uma configuração no CloudWatch, por exemplo, para que esse cara aqui, se não tiver ninguém nessa fila, o serviço do ECS recebe zero. Se tiver alguém nessa fila, o serviço do ECS recebe um e entra com escalabilidade por profundidade de fio. É uma das formas da gente pensar. Pessoal, essa é uma arquitetura, eu entendo que ela ficou um pouco grande, maior do que a gente esperava, né? Poderíamos fazer aqui alguns exemplos menores, mas olha só, você tem um projeto agora de checkout com alguns itens, com filas, usando features da AWS e você notar eu não usei quase nada de outras coisas né porque a maioria dos itens são auto configuráveis o pedido tem que morar para sempre? Gente eu posso esvaziar esse Dynamo depois colocar ele pra um guardar esses dados em um bucket entendeu? então assim as formas são muito variáveis de uso aqui, tá? Bom, é isso. Não vamos fazer essa arquitetura, desculpe, frustrar essa expectativa. Não vamos criar tudo isso agora na nossa conta, tá bom? Porque seriam projetos muito grandes e aqui a gente teria que fazer vários códigos do ECS, vários códigos para tampar esses itens aqui, tá bom? Aí você vai falar, nossa, o ECS aguenta? Gente, o ECS aguenta. O ECS não pede nada para outras plataformas de containers. Então, se você for fazer assim, uma arquitetura voltada a AWS, você quer ter facilidade, usa o excesso do Fargate ah, mas se eu fizer em Kubernetes pode fazer em Kubernetes usando EKS ele vai ser um pouco mais demorado para você chegar nos seus objetivos por questões de configuração do próprio Kubernetes se você usar o Kubernetes com Fargate você não vai ter todo o apoio e recurso de rede que você poderia ter, tá bom? Mas usando ele com EC2 você usaria ele como Kubernetes em qualquer lugar, né? Porém, você pode ter mais responsabilidade sobre máquinas. Se você quer fazer isso aqui muito rápido, usa o EC2 com o FireGate, só vai fazer o cluster, testes com o FireGate, com o Fargate, só vai fazer o cluster task Fargate, entendeu? Sobe, baixa a task quando tiver que baixar, delega para o recurso de auto-scaling, faz auto-scaling por CPU, faz auto-scaling por memória, faz auto-scaling por TPS dos seus CMRs, faz por recurso de fila, profundidade de fila, então tem várias formas de melhorar aqui. Lembrando, não está representado aqui, mas todas essas aplicações são nativamente logadas no CloudWatch. Tá bom? Nativamente elas são logadas no CloudWatch. Então, tudo que você jogar de logs aqui dentro cai no CloudWatch e você pode usar o Log Insights para fazer carries. Legal? Para fazer pesquisas de tudo isso aqui. Cada serviço, um com sua própria responsabilidade, um com sua própria base de dados, com suas próprias filas de conexão e a AWS muito bem representada aqui dentro. Bom, é isso. espero que vocês tenham gostado, agradeço a presença de vocês até aqui e mais uma vez, boa sorte!