Fala galera, beleza? Vamos falar agora mais um pouquinho sobre um outro serviço que a gente tem da AWS que é Serverless. O SQS é um serviço que a gente usa muito no dia a dia também. Esse é bem utilizado pelos times mesmo, porque aqui a gente está falando de mensageria. Quando a gente está falando, por exemplo, de uma fila de mensagens para a gente processar as coisas, por exemplo, de forma assíncrona. uma fila de mensagens para a gente processar as coisas, por exemplo, de forma assíncrona. Então, quando a gente está falando de aplicações hoje em dia que estão trabalhando de forma assíncrona, a maior parte das vezes vocês vão ver o SQS aparecendo. Ele aparece muito no dia a dia. Ele basicamente é um serviço gerenciado pela AWS, ou seja, ele é serverless. Você vai ter aquelas mesmas facilidades que o Lambda Function tem, só que para processamento de fila. Então, ele vai fazer toda a gestão de subida, de armazenamento, de tamanho, etc., para um processamento em fila, colocando escalabilidade e assim por diante, para você poder fazer seus microserviços trabalharem lendo essa fila. Então, basicamente, para você que conhece processamento assíncrono em fila, esse carinha é o que vai te ajudar no dia a dia. E o fato dele ser serverless vai te ajudar muito a não ter que ficar pensando naquele monte de coisa que a gente falou de infraestrutura, etc. E assim por diante. Você consegue deixar ele totalmente desacoplado do seu código e com isso você também não trava outra parte do sistema por conta disso. Então é basicamente essa a grande ideia. Vamos entrar um pouco mais. O SQS tem dois padrões de processamento em fila. O primeiro dos padrões é essa fila padrão que a gente está falando mesmo. Na fila padrão, o que ele vai fazer? Ele vai fazer a mensagem ser lida pelo menos uma vez, tentando respeitar a ordem. O que isso significa? quando ele estiver recebendo mensagens imagina que está criando as mensagens está colocando as mensagens na fila o consumidor, ele vai tentar pegar em ordem, tá bom? e o SQS vai garantir que você vai ler pelo menos uma vez essa fila de processamento aqui beleza? essa ordem de pedidos, vamos chamar assim. Então você tem lá a ordem de mensagens que você tem dentro do SQS. Esse consumidor vai tentar pegar na ordem. Se por algum acaso essa ordem mudar um pouquinho, ele vai continuar funcionando, mas ele vai garantir que a sua fila está sendo lida por inteiro. Então a ordem ele tenta garantir, mas ele não garante totalmente que a ordem vai ser seguida. Então se você tem uma aplicação normal aqui do dia a dia, por exemplo, uma aplicação onde você tem que ler todos os pedidos de compra de torradeira que você teve lá no seu site. Bom, você colocou todos os pedidos de compra e isso vai sendo lido. Se a torradeira sair primeiro pra mim ou pra você, pouco importa pro seu sistema, porque você já garantiu o estoque antes, então aqui você só precisa garantir que você vai processar pagamento, por exemplo, assim por diante. Então a ordem, pouco importa. Você vai colocar lá e você só precisa garantir que seja lido, beleza? Então pra esse tipo de coisa é uma fila padrão. Agora vamos dar um outro caso. Essa fila FIFO é o contrário. Na verdade não é o contrário. Ela tem um ponto adicional. Ela vai garantir que as mensagens sejam entregues, processadas uma vez e na ordem. Então, por exemplo, se você falar, poxa, eu preciso fazer um processamento de ingressos para o show. Sei lá. Se bem que ingressos para o show você também consegue garantir estoque antes. Mas imagina que você tem uma... Bom, ótimo. Na hora que você vai fazer compra para show, imagina que hoje em dia a maior parte das empresas fazem uma fila para você entrar na compra. Nem acho que ela é tão real assim, mas seria uma ótima oportunidade de você fazer isso. Quando você vai ter que criar uma fila de quando cada um vai entrar ali, os próximos dias que vão entrar, essa opção pode ser uma boa ideia, porque você precisa garantir a ordem daquilo. Para um processamento do dia a dia que eu vejo muito, é por exemplo para você processar pagamentos. Imagina que eu tenho que fazer o processamento de pagamentos da sua conta corrente, por exemplo. Para fazer esse processamento de pagamentos, eu tenho uma ordem de prioridade de pagamento. Imagina que, sei lá, eu preciso receber primeiro o seu pagamento da fatura do cartão, porque o seu juros é mais alto do que receber o pagamento do boleto, por exemplo, e assim por diante. Então você pode fazer uma priorização, entendeu? Essa é a grande sacada dessa fila CIFO aqui. Elas são para processamentos que são mais detalhados e que você precisa garantir também a ordem e não só o consumo apenas uma vez beleza então tem esses dois tipos aqui pra gente usar no dia a dia quando está falando de configurações gerenciamento de um sqs você tem que lembrar que você vai ter é algumas coisas aqui pra fazer tá bom a primeira coisa é a criação da fila que a fila pode fazer pelo clipe você pode fazer também pelo console aws ou até pelas de k você consegue fazer a criação da fila desses dessas formas todas você vai ter esse dele que do o dele que aqui é o dedo lhe lhe rui qual é a grande a grande sacada dessa do dele que ele quer o seguinte imagina que estava fazendo a leitura da fila e por algum motivo, alguma mensagem, algumas mensagens não conseguiram ser lidas. Elas tentaram várias vezes, vai ser tentativa. Chega uma hora que você tem que jogar isso para uma fila para você analisar de novo. Então, imagina que você foi lá, foi lendo, teve uma aplicação, ficou tentando ler uma mensagem, não conseguiu, não conseguiu, não conseguiu, não conseguiu. Se você for deixando isso o tempo todo dentro da fila, essa fila pode ficar com um tamanho muito grande. Imagina que começou mais de um registro, dois, dez registros fazendo isso. Chega uma hora que a sua fila fica muito grande e você vai começar a ter problemas. Então, qual que é a sacada? Você começa a pegar essas tentativas, joga para um DLQ e depois você volta para analisar esse DLQ. Aí que você pode colocar tanto inteligências para fazer um retry diferente, por exemplo. Eu já peguei casos de resiliência onde a gente lia o DLQ, fazia a inclusão, por exemplo, de um parâmetro diferente com base no que tem no DLQ e depois tentava reprocessar. Mas quando você não tem uma inteligência de aplicação nesse nível, você volta no DLQ, entende o que tem ali dentro, para depois ver o que você vai fazer com essa galera aí que não conseguiu ser processada. Possivelmente você vai ter que mexer no seu sistema em algum momento, porque as suas mensagens não estão tão boas assim, beleza? Tem uma outra coisa também que são as políticas de acesso. Como sempre, a gente vai estar falando aqui de segurança, e como segurança você tem que declarar lá quem que pode ler a sua fila e quem pode gravar na sua fila. Então dentro da política de acesso que a gente comentou aqui durante o curso, você vai ter que colocar isso. E outra coisa também é o monitoramento que a gente faz com o CloudWatch e o monitoramento é importante você monitorar o que está entrando, o que está saindo, essa velocidade de leitura e gravação da fila e o tamanho dela. Muita gente esquece de olhar o tamanho e daí a fila começa a ficar muito grande e chega uma hora que ela para e começa a dar vários problemas. A fila fica muito grande, você não tem profundidade de fila e começa a capotar. Então aqui é interessante no CloudWatch você ter alertas para tudo isso, beleza? Outra coisa que a gente tem aqui de funcionalidades avançadas do SQS que é legal vocês saberem. A primeira coisa é a visibilidade da mensagem. O que é a visibilidade da mensagem? É o seguinte, imagina que eu fui lá e coloquei 10 mensagens na fila. Tá bom? Eu tenho 5 consumidores, não tenho só, tem 5 caras consumindo. O primeiro pegou essa mensagem. A partir do momento que ele pegou, ele coloca essa mensagem oculta. Ele flega lá na mensagem falando que a partir de agora essa mensagem não vai ser mais vista por outros consumidores. Essa mensagem continua na fila, mas ela continua de forma oculta. Ou seja, todo mundo que vier buscar não vai ver mais a mensagem. Está na mão do primeiro consumidor. Caso esse primeiro consumidor não responda depois de X tempo essa mensagem volta agora caso e ele não aceita mais o consumo desse consumidor então pensa assim, eu tenho 5 caras, 10 mensagens o primeiro consumidor foi lá, buscou a primeira mensagem e deixou como oculta se o processamento dele aconteceu ok ele volta e deleta a mensagem se não apareceu ok essa mensagem volta para a tentativa de outro consumidor buscar. Para usar isso, precisa ser bem inteligente, porque qual é a ideia? Se você está tirando a gestão de consumo única daqui, porque você concorda que você colocou aqui a gestão de realização do consumo no consumidor. Então, se esse consumidor leu e esqueceu de deletar você vai consumir 12 vezes beleza? se o consumidor leu e deu a resposta falando que está tudo ok, ok fechou já era beleza agora se o consumidor leu e e seguiu a vida ali deu tudo certo beleza se ele leu e esqueceu de deletar, pode ter um problema ou seja, você tem que garantir a deleção dessa mensagem pra ela não voltar a ser visível, aqui é legal porque você garante a resiliência da aplicação se você mata a mensagem e o consumidor capota por algum motivo, você perdeu, já era então eu acho ela mais interessante mas é mais complexa de utilizar muita gente não usa isso porque não quer levar para o consumidor essa estratégia de vir aqui e deletar. Quando a gente tem áreas separadas dentro da empresa fazendo consumo de fila, isso acontece bastante, da gente não usar isso. Porque daí, putz, eu não quero deixar na mão do meu consumidor isso. Mas você também pode fazer o contrário. Você pode deixar na sua mão algum tipo de estratégia para você deletar caso o consumidor não consiga e assim por diante. Bom, tem várias estratégias que dá para fazer aqui, mas vocês entenderam, né? Você está deixando essa mensagem oculta para os demais não conseguirem pegar por um tempo. Essa parte de retenção da mensagem é o tempo automático de deleção. Independentemente da estratégia de visibilidade de mensagem, é o tempo que você vai deixar essa mensagem ali disponível para conseguir ser consumida tá bom e aqui o tamanho das mensagens que a gente pode ter no sqs são mensagens de 250kbytes em qualquer formato ali tipo xml json e assim por diante tá formato de texto beleza