Entenda as diferenças entre o SQS e o SNS
Tags: aws, sqs, sns, eventdriven
Published: 2024-01-30 23:03:15

{% embed https://www.youtube.com/watch?v=IlLtVlUxJVk %}

**_[TRANSCRIÇÃO]_**

## Introdução

O SQS e o SNS são dois serviços da AWS que possuem nomes bem parecidos, porém o caso de uso de cada um desses dois aqui é um pouco diferente. No vídeo de hoje, a gente vai entender a diferença e quando utilizar um ou outro. 

Então, sem enrolação, bora já entender o que é o SQS.

## SQS (Simple Queue Service)

Então, arrastando um pouco para a direita, o SQS, pela sigla, é basicamente o Simple Queue Service. É um serviço de fila da AWS onde ele tem um comportamento, como o nome já diz, de fila.

O SQS, por ser um serviço de fila, ele tem produtores e consumidores de mensagens. Os produtores, também chamados de producers, publicam mensagens para a fila, e essa fila do SQS vai armazenando essas mensagens para que elas possam ser consumidas depois, posteriormente, por outras aplicações.

Então, por exemplo, se a gente tem aqui um produtor que publicou, por exemplo, essa mensagem A dentro da fila, a gente vai ter aqui dois consumidores que estão interessados em tudo que acontece dentro dessa fila no SQS. Então, esses consumidores aqui têm um comportamento de pulling. A cada, por exemplo, 5 segundos, eles chamam ali um endpoint, digamos assim, do SQS para poder verificar se tem novas mensagens.

Como o produtor um acabou de publicar essa mensagem A, o consumidor em questão que fez ali esse pulling acaba consumindo essa mensagem, e ela vai diretamente aqui para o nosso consumidor um. Vamos supor que passou o tempo, e agora o produtor 2 publicou a mensagem aqui B. Então, o consumer 1 e o 2, eles vão ficar fazendo pulling através desse SQS, e caso tenha essa nova mensagem aqui na fila, eles também vão fazer o consumo, e essa mensagem também poderia ir ali diretamente pro consumer 2.

Um ponto interessante que a gente tem aqui do SQS é que a mensagem ela vai ser consumida pelo menos uma vez por esses consumidores. Então, grande parte das vezes, essa mensagem, por exemplo, C, se ela estiver na fila, ela não deveria ser consumida por esse consumidor e também por esse. Essa mensagem vai ser consumida na maior parte das vezes por apenas um consumidor. Então, se a gente for parar para pensar, o que caracteriza um SQS, basicamente, ele é um sistema de filas. Ou seja, a mensagem ela vai ficar enfileirada ali até que ela seja consumida por um consumidor.

Um ponto interessante aqui é que a mensagem ela vai ser consumida pelo menos uma vez. O SQS ali, ele não tem a garantia que vai ser exatamente uma vez, mas ele consegue indicar que vai ser pelo menos uma vez. Então, raramente, essa mensagem pode ser consumida duas vezes, né, mas é um cenário bem improvável que aconteça, mas ele pode acontecer.

### Caso de uso

Mais um ponto aqui de caso de uso do SQS é que ele é bastante utilizado para fazer um desacoplamento entre microsserviços. Então, por exemplo, vamos supor que esse producer um e esse consumer um sejam duas aplicações Java diferentes, por exemplo, ou poderia ser de outra linguagem também. E vamos supor que essa fila aqui ela é um meio de desacoplamento entre esses dois serviços.

Então, vamos supor que esse producer um, ele quer realizar a criação de um usuário. Quem realiza essa ação de criação de fato é o consumer 1. Então, ao invés do producer 1 chamar diretamente o consumer 1, ele vai enviar pra fila um comando, digamos assim, realize a criação desse usuário, passando ali todo o seu JSON, o seu payload, e o consumer 1 iria pegar essa mensagem e consumir, e aí sim, de fato, realizar essa persistência desse usuário, por exemplo.

Dessa forma, a gente diz que a gente tem um desacoplamento, porque caso o serviço aqui do consumer 1, ele não esteja online, por exemplo, no momento que o producer ele quer realizar a criação desse usuário, a mensagem ela vai ficar na fila por até 14 dias, dando tempo aqui desse consumer né se recuperar, ficar saudável ali para depois ele consumir e fazer a criação desse usuário.

Então, o SQS, ele é bem utilizado ali num contexto de microsserviços para ter esse desacoplamento, que a gente chama entre duas aplicações. Beleza, agora eu acho que o SQS a gente já passou rapidamente. Vamos entender agora um pouco sobre o SNS. Então, vamos aqui para baixo para entender um pouco mais sobre o SNS.


## SNS (Simple Notification Service)

O SNS ele se difere um pouco ali do SQS até na questão do nome. O SQS ele indica ali que é um Simple Queue Service, ou seja, um serviço simples de fila, digamos assim. E o SNS é um Simple Notification Service, ou seja, um serviço de notificação simples ali. Então, a gente já tem uma pequena diferença ali que um é o sistema de fila, e o outro é um sistema de notificação.

Mas o que seria de fato né esse sistema ali de notificação? 

Um sistema de notificação é basicamente quando a gente tem aqui, por exemplo, o nosso producer, e ele quer indicar que algo aconteceu no sistema, e ele quer comunicar isso para diversas pessoas, ou seja, para diversos consumidores que podem estar em diversos canais diferentes.

Então, quando esse producer ele envia essa notificação pro SNS, que é o serviço de notificação simples ali, digamos assim, o serviço de notificação ele vai ter uma inteligência de fazer o roteamento dessa notificação para diversos meios ali de comunicação. Então, o SNS ele pode redirecionar essa mensagem, por exemplo, esse evento A, ele pode redirecionar esse evento A para uma fila SQS, passando aqui esse evento A, ele pode indicar para uma outra fila SQS também, indicando esse evento A.

E caso a gente queira também, a gente pode plugar aqui um sistema de e-mail, para assim que surgir essa notificação, a gente também ter ali um envio desse e-mail, por exemplo, desse evento A. Além disso, a gente tem diversas opções aqui. Além de trigar um SQS, a gente também poderia fazer ali o envio de push notification pro celular do usuário.

Então, o SNS ele vai te facilitar quando você tem alguma coisa que aconteceu no seu sistema e esse evento, né, algo que aconteceu, ele precisa ser notificado para diversas pessoas. Então, esse fluxo de comunicação é basicamente aquele que a gente diz que é um para muitos, né, ou também chamado de broadcast ou pubsub. Com ele, o nosso producer envia uma única vez esse evento, e o SNS, o sistema de notificação, é responsável por entregar isso para todos os outros consumidores.

Então, o ponto interessante que a gente tem aqui é que a gente pode plugar o SQS, que a gente viu ali momentos atrás, junto com o SNS. Então, a gente vai ter um evento, por exemplo, o evento B aqui que a gente emitiu, e ele vai ser enviado pro SQS 1, e esse evento B também vai ser enviado aqui pro SQS 2. Dessa forma, esses nossos dois consumers eles vão consumir a mensagem separadamente, porque estariam em duas filas diferentes.

Então, por exemplo, esse evento B seria consumido aqui pelo consumer um, ele poderia ser consumido, por exemplo, 10 horas da manhã, que é o momento que ele levantou, digamos assim, para processar, e o consumer 2, vamos supor que ele só vai processar essa mensagem 4 horas da manhã. Então, essa mensagem B aqui ela ficaria esperando, né, até o consumer 2 levantar para poder realizar esse consumo, e quando isso acontecesse, ele tiraria aqui a mensagem da fila, e ele conseguiria fazer tudo certinho.

Então, pra gente ver aqui os pontos que caracterizam, né, um SNS, é basicamente que ele é um sistema de notificações. Ali, um pubsub, naquele esquema de broadcast, né. Então, a gente fala uma vez e fala para todo mundo. A gente pode ter como destino um SQS, e-mail, push notification e diversas outras opções ali que a AWS oferece integração ali com SNS, por exemplo.

E mais um ponto bem interessante aqui que caracteriza é que a mensagem ela vai ser enviada para diversos consumidores. Então, diferente do SQS, que a mensagem é consumida apenas uma única vez, no SNS, a gente pode enviar uma mensagem, e ela vai ser consumida por diversas pessoas. 

### Caso de Uso

Então, por exemplo, um caso de uso que tem bastante aqui de um SNS, a gente poderia ter um sistema orientado a eventos, né. Por exemplo, onde a gente teria uma API, um microsserviço, vamos supor que esse nosso producer aqui ele é o nosso microsserviço de usuário ali, que tem todo esse cadastro.

E assim que ele realiza o cadastro de um determinado usuário, ele emite um evento aqui indicando que esse usuário ele foi criado. Então, assim que esse evento ele foi emitido, esse evento ele seria redirecionado, por exemplo, para duas filas. Poderia ser uma fila ali onde teria aplicação do setor de marketing da empresa, por exemplo. Aqui, a gente teria um outro consumidor que seria ali do setor de produtos, por exemplo, dessa empresa.

Então, assim que o usuário é criado, o setor ali de marketing, o setor de produtos da empresa já são notificados para talvez enviar um e-mail, para talvez oferecer ali um determinado desconto, fazer um e-mail marketing. 

Então, a gente consegue aqui deixar a nossa arquitetura também orientada a eventos. Então, o SNS ele vai te ajudar quando você tem esse evento ali crítico dentro do seu sistema ou muito importante, e ele vai enviar isso para todo mundo que precisa.

## Conclusão

Bom, então é isso. Eu espero que você tenha gostado do estilo do vídeo de hoje. Foi um vídeo bem rápido pra gente só dar um contexto aqui de qual a diferença, né, do SQS pro SNS. 

E caso tenha ficado com alguma dúvida ou tem algum ponto ali de sugestão, coloca aqui embaixo nos comentários. 

Então, antes de você sair, deixe seu like embaixo, se inscreve no canal e acompanha lá a gente nas redes sociais. Um grande abraço e até a próxima.