Bom pessoal, no vídeo anterior, o que a gente acabou fazendo? Nós pensamos em adicionar esse serviço aqui, que acaba gerando esses códigos para a gente, mas infelizmente a gente tem um problema ainda. Nós temos esse ponto único de falha aqui. E esse ponto único de falha pode inviabilizar o meu negócio, caso eu tenha algum problema com a minha gateway. Então, o que nós vamos fazer aqui? Nós vamos tentar solucionar esse problema. E uma das formas para a gente solucionar esse problema é simples, se você pensar. É uma opção lógica, que é não usar apenas uma gateway eu posso utilizar várias gateways de uma vez e se eu tiver problema com uma, eu uso outra olha só que sensação né que coisa simples a gente conseguir entender porém o que acontece quando vou trabalhar com mais uma gateway eu preciso de uma implementação mais organizada, porque eu posso querer adicionar outras gateways ainda. Então, vamos imaginar que eu quero adicionar três gateways de pagamento, e se uma estiver fora, eu vou para a outra e vou para a outra, e assim as coisas funcionam dessa forma. Como que eu posso fazer aqui para a gente resolver esse ponto da gateway de pagamento? Primeira coisa que a gente tem que pensar aqui nesse ponto. Eu não posso sair chamando direto uma Gateway de pagamento, porque eu preciso ter um sistema que consiga fazer essas verificações se a Gateway está disponível ou se está acontecendo algum problema. Então, olha só o que a gente vai fazer. Ao invés de eu colocar Gateway de pagamento aqui tá eu vou chamar isso aqui de gay acl o que significa acl antes corrupção layer ou seja um leirante corrupção ou seja ao invés de eu amarrar o meu sistema diretamente com a gateway, eu tenho um sistema intermediário. E esse sistema intermediário, o que ele vai fazer? Ele sim vai fazer a comunicação com o gateway. Ou seja, eu não sujo essa minha regra, essa minha aplicação, essa minha implementação com nenhuma gateway. Esse sistema chama um serviço meu de gateway e esse serviço de gateway chama as gateways que a gente precisa. Então, nesse caso, o que eu posso fazer? Aqui eu posso colocar, vamos lá, a gateway número 1. Aqui eu posso colocar a gateway número 2 e aqui eu posso colocar a gateway número 3. Vamos colocar dessa forma aqui, 2, a gateway número 3. E agora, na hora que eu preciso fazer a chamada, esse cara tenta essa. Se tiver problema com essa, esse cara vai e tenta essa. Se tiver problema com essa, esse cara vai e tenta essa aqui. Legal? Isso aqui vai dar uma tranquilidade muito maior para que a gente consiga trabalhar. Deixa eu até mudar a corzinha disso aqui para ficar mais claro aqui para a gente do que a gente está fazendo. do que a gente está fazendo. Então, esse Gateway ACL, ele é responsável por gerenciar as Gateways para fazer as chamadas nas Gateways que estão disponíveis para mim naquele momento. E aí, eu não misturo mais esse meu problema e eu minimizo o risco de eu ficar fora do ar porque há uma possibilidade muito pequena de todas as minhas gateways estarem fora do ar. E se tiver acontecer esse tipo de situação, você pode ir adicionando mais gateways. O grande ponto é que você não tem um acoplamento muito forte da sua aplicação com apenas uma gateway de pagamento. Então, isso aí é um ponto importantíssimo que você tem que pensar. Legal? importantíssimo que você tem que pensar legal então com isso aqui ó eu minimizo esse meu risco de ficar fora do ar e de uma forma geral eu acabo tendo aqui um design vamos dizer assim simples mas interessante da minha aplicação eu compro minimizar esses tipos de problema minimizar esse problema aqui crema tive uma solução interessante aqui também pra eu não ficar gastando muito tempo e agora eu tenho uma solução que aparentemente aqui pra mim começa a ser adequada não sei se você conseguiu se ligar né o como é importante você saber quais são os pontos que podem te atrapalhar, quais são os pontos que estão legais e que podem gerar qualquer tipo de problema. Uma observação aqui que eu quero fazer é, muita gente pode ter pensado, por que você não coloca uma fila aqui para gateway de pagamento? Em muitas situações isso seria verdade tá porque porque eu não dependo de uma conexão síncrona para eu realizar o meu pagamento ou seja se você foi numa amazon david fizer uma compra você vai ver que ele nem pensa para dar o resultado porque porque aquele pagamento ele é feito assíncrono se der algum problema depois ele te manda um e-mail pedindo para mudar o número do cartão por exemplo entendeu eu poderia fazer isso poderia mas a gente tem um ponto aqui. Eu preciso saber imediatamente se o cara pagou. Lembra que eu quero consistência? Eu não quero ter uma consistência eventual aqui. Por quê? Porque eu não posso ter a chance de perder uma venda ou alguém que está tentando comprar determinado ingresso pelo fato de um lag que aconteça assíncrono com o meu pagamento, eu acabo tendo esse tipo de problema. Aqui não. Aqui eu sei imediatamente se a compra foi aprovada. Então, existem situações que eu posso fazer o pagamento de forma assíncrona, que é o que acontece com a maioria dos e-commerce, mas existem situações que eu não posso porque é um requisito do sistema porque pode afetar diretamente o meu negócio tá? então tá aqui não tô dizendo que não pode ter um site de ingresso que faça essa parte assíncrona, pode até ter mas da forma como a gente tá olhando aqui fazer isso de forma assíncrona garante muito mais que eu vou manter consistência ao invés de disponibilidade. Então olha só que interessante teorema CAP aqui na veia aqui para a gente ainda. Beleza? Bom, próximo vídeo a gente vai falar sobre modelagem de dados, como que a gente enxerga esses tipos de coisa aí para a gente. Beleza? Então vamos nessa.