Serverless além de Lambda: conciliando API Gateway, SNS e SQS na prática
Sistemas serverless de verdade vão muito além de uma Lambda solitária. Neste artigo, vamos entender como combinar comunicação síncrona com APIs (REST e HTTP) através do Amazon API Gateway e comunicação assíncrona com arquitetura orientada a eventos usando Amazon SNS e SQS. Vamos passar pelos conceitos, ver quando usar cada um e desenhar um sistema completo na prática.
Se preferir consumir esse conteúdo em forma de vídeo, veja nosso canal do youtube:
Serverless é mais do que Lambda?
Quando falamos sobre Serverless na AWS, é comum as pessoas imediatamente pensarem em AWS Lambda . E elas não estão erradas, é um serviço importante, mas Serverless na AWS é muito mais do que isso.
Serverless é um modelo de construção e execução de sistemas em nuvem no qual a provedora de nuvem administra toda a infraestrutura de servidores e os desenvolvedores podem focar no código e na lógica de negócio. Para isso, precisamos de solução de compute (como Lambda) para executar as aplicações, mas também de outros serviços que nos ajudam a montar a comunicação síncrona e assíncrona entre componentes. É aí que entram o API Gateway , SQS e SNS .
Mas antes de sair falando de serviços, vamos recapitular rapidamente alguns conceitos importantes.
Comunicação síncrona X assíncrona
A comunicação síncrona é aquela em que quem faz a chamada espera pela resposta antes de seguir em frente. É como uma ligação telefônica, você liga, a pessoa atende, conversa em tempo real, e só depois você faz outra coisa. Faz sentido quando a próxima ação depende do resultado imediato, como validar se o cartão tem saldo antes de confirmar uma compra.
A comunicação assíncrona é aquela em que quem dispara a ação não espera o resultado pra continuar. É como mandar uma mensagem de texto, você envia e segue a vida. Funciona bem quando a próxima ação não precisa do resultado imediato, como confirmar a compra antes de saber que a entregadora planejou a rota de entrega.
Em termos de sistema, uma das maneiras mais comuns de vermos comunicação síncrona é através de APIs pelo modelo cliente-servidor. Nele, o cliente faz uma requisição e fica esperando a resposta do servidor, parando outras tarefas enquanto não é respondido.
Já para comunicação assíncrona entre sistemas, uma solução clássica é usar uma arquitetura orientada a eventos através de serviços de mensageria. Nesse modelo de arquitetura, os sistemas se comunicam entre si através de mensagens. Um serviço manda uma mensagem para o outro informando de algum evento que aconteceu e continua seu processamento normalmente sem esperar uma resposta.
Vamos entrar a fundo nos conceitos e serviços que rodeiam esses modelos.
O que são APIs
API é a sigla pra Application Programming Interface, ou interface de programação de aplicações. Na prática, é um contrato que define como duas aplicações diferentes podem trocar informações entre si. O contrato especifica o que o cliente pode pedir, em qual formato, e o que ele vai receber de volta.
Esse contrato existe pra padronizar a comunicação e proteger a lógica e os dados por trás. O cliente não precisa saber como o servidor processa a requisição nem como os dados estão organizados internamente, ele só precisa seguir o que está definido na API. Isso traz duas vantagens grandes: o cliente fica desacoplado da implementação interna do servidor (que pode mudar sem quebrar o cliente) e os dados não ficam expostos diretamente.
APIs são o mecanismo padrão pra implementar comunicação síncrona no modelo cliente-servidor. O cliente faz uma requisição seguindo o contrato da API, espera, e recebe a resposta.
Cada chamada a uma API combina dois ingredientes: um método HTTP, que diz qual ação a gente quer realizar, e uma rota, que aponta sobre qual recurso queremos agir, como ilustrado no diagrama abaixo.
Conhecendo o Amazon API Gateway
O Amazon API Gateway é o serviço da AWS que cria e gerencia APIs. Ele funciona como uma porta de entrada do seu sistema: o cliente bate no API Gateway, e ele encaminha a requisição pro backend certo.
Mas ele faz mais do que só rotear chamadas. Por baixo dos panos, o API Gateway cuida de várias coisas chatas que você não precisa implementar:
- Autenticação e autorização — valida tokens JWT, integra com Amazon Cognito ou chama uma Lambda authorizer
- Throttling e rate limiting — protege seu backend de picos inesperados de tráfego
- Logs e monitoramento — manda métricas pro Amazon CloudWatch automaticamente
- HTTPS — todas as APIs têm certificado e criptografia configurados de fábrica
- Versionamento — permite manter várias versões da API rodando ao mesmo tempo
Tudo isso sem precisar provisionar nem manter servidor algum. Você define as rotas, conecta às Lambdas, e o serviço escala automaticamente.
REST vs HTTP API
Quando você cria uma API no API Gateway, precisa escolher entre dois tipos: REST API ou HTTP API. Os nomes podem ser um pouco confusos, porque toda REST API, por definição, também usa HTTP. A diferença está no conjunto de funcionalidades que a AWS oferece em um caso ou outro.
A REST API no API Gateway é a versão completa, com todos os recursos avançados de gerenciamento. A HTTP API é uma versão mais enxuta, com latência menor e custo mais baixo.
A tabela abaixo resume os principais pontos de diferença entre os dois para te ajudar a decidir entre elas. Os detalhes de todas as funcionalidades estão na documentação oficial da AWS .
| Atributo | REST API | HTTP API |
|---|---|---|
| Custo | US$ 3,50 / milhão de requests | US$ 1,00 / milhão de requests |
| Latência | Maior | Menor |
| Chaves de API e throttling por cliente | Sim | Não |
| Cache de respostas | Sim | Não |
| Endpoints privados (acesso só via VPC) | Sim | Não |
| Integração com AWS WAF | Sim | Não |
Como escolher: se você está construindo um sistema simples e não precisa de funcionalidades avançadas de gerenciamento, HTTP API é a escolha mais econômica e rápida de configurar. REST API entra em cena quando você precisa de chaves de API por cliente (tipo planos diferentes pra cada parceiro), endpoints privados que só rodam dentro de uma VPC, ou proteção avançada com AWS WAF.
O que é arquitetura orientada a eventos
Arquitetura orientada a eventos (ou event driven architecture) é um estilo de arquitetura de software em que componentes se comunicam emitindo e processando eventos, registros imutáveis que representam algo que aconteceu.
Esse modelo se apoia em 3 entidades: produtores que criam e mandam mensagens, consumidores que recebem e processam as mensagens e uma infraestrutura intermediária responsável pelo direcionamento das mensagens para os consumidores.
Na AWS, os serviços intermediários mais famosos (e serverless!) são o Amazon SQS e o Amazon SNS.
Conhecendo o Amazon SQS
O Amazon SQS (Simple Queue Service) é o serviço de filas da AWS. Ele recebe mensagens de um produtor, segura essas mensagens e entrega cada mensagem para um único consumidor.
Na hora de criar uma fila, o SQS oferece dois tipos: Standard e FIFO.
- Filas Standard priorizam alta vazão. Elas conseguem processar um número quase ilimitado de mensagens por segundo e garantem que cada mensagem será entregue pelo menos uma vez. O preço dessa flexibilidade é que, ocasionalmente, uma mensagem pode ser entregue mais de uma vez ou chegar fora de ordem.
- Filas FIFO (First-In-First-Out) garantem que as mensagens são processadas na ordem exata em que foram enviadas e que cada mensagem é entregue exatamente uma vez, sem duplicatas. Esse rigor a mais vem com um limite menor de vazão e custo um pouco mais alto.
A escolha entre as duas depende do seu caso. Se a ordem das mensagens importa ou se duplicatas podem causar problemas, use FIFO. Se você só quer um buffer rápido e seu consumidor já trata mensagens duplicadas na implementação, Standard é mais barato e escala mais.
Conhecendo o Amazon SNS
O Amazon SNS (Simple Notification Service) é o serviço de tópicos da AWS. A diferença de um tópico para uma fila é que em vez de uma mensagem ir para um único consumidor como no SQS, no SNS a mensagem é entregue para todos os assinantes daquele tópico ao mesmo tempo.
Esse comportamento se chama fan-out e é o que torna o SNS poderoso pra notificar várias partes do sistema de uma vez. Um produtor publica uma mensagem no tópico, e o SNS replica a mensagem pra cada assinante inscrito.
Outro diferencial do SNS é a variedade de protocolos de assinatura suportados. Um assinante de um tópico pode ser:
- Uma fila SQS (que direciona para um único consumidor depois)
- Uma função Lambda (acionada diretamente pela mensagem)
- Um endpoint HTTP/HTTPS (pra integrar com sistemas fora da AWS)
- Um email (a AWS manda a mensagem pro endereço cadastrado)
- Um número de celular (envio de mensagens por SMS)
- Um app mobile (push notification via APNs ou FCM)
O que são microsserviços
Por último, vou aproveitar para falar de microsserviços, que têm tudo a ver com sistemas resilientes que combinam diferentes modelos de comunicação.
Microsserviços são pequenos serviços independentes que, juntos, formam uma aplicação maior. Cada um cuida de uma responsabilidade bem específica e se comunica com os outros através de chamadas de rede. Em um sistema serverless na AWS, é comum vermos cada microsserviço ser implementado com uma ou mais funções Lambda.
Trazendo os conceitos para a prática
Nada melhor para solidificar conceitos do que ver eles sendo usados de verdade. Então vamos montar um sistema que combina tudo o que vimos até agora!
O que vamos construir
Imagine que estamos construindo um sistema para uma pizzaria. Em um fluxo bem simplificado, queremos que o sistema possibilite algumas coisas:
- Clientes devem poder fazer seu pedido e realizar o pagamento pelo sistema
- Clientes devem receber um email contendo a confirmação do pedido e sua nota fiscal
- Os cozinheiros devem ser informados dos pedidos que devem preparar
- O sistema deve determinar qual é o melhor entregador para fazer a entrega, considerando outros pedidos em uma rota otimizada
- O entregador deve ser notificado por SMS da atualização de sua rota e novos pedidos a serem entregues
- Clientes devem conseguir saber se seu pedido já saiu para entrega
Planejando o sistema
No diagrama acima, colocamos todas as funcionalidades para uma mesma entidade abstrata chamada simplesmente de "sistema". Mas como vimos no framework de planejamento de sistemas que apresentei no artigo sobre arquitetura orientada a eventos, podemos começar o design do nosso sistema quebrando as diferentes funcionalidades em microsserviços especializados.
Nos dois pontos em que usuários precisam interagir diretamente com o sistema, vamos criar uma interface gráfica para essa interação. Assim, criamos uma interface para os clientes e outra para os cozinheiros, cada uma com seu backend. Para as demais funcionalidades, criamos um microsserviço para cada uma.
Agora está na hora de entender que pontos dessa comunicação precisam ter respostas síncronas e quais podem ser assíncronas:
| Comunicação síncrona | Comunicação assíncrona |
|---|---|
| Cliente fazendo pedido; Cliente pagando; Cozinheiros consultando pedidos a fazer | Envio de nota fiscal por email; Planejamento de rotas; Notificação do entregador |
Desenhando a conexão entre partes
Agora que temos a visão geral do sistema, podemos nos aprofundar no nível técnico e desenhar a arquitetura.
Para os pontos onde precisamos de comunicação síncrona, vamos usar comunicação com APIs através do API Gateway. Já para os pontos assíncronos, vamos definir uma comunicação orientada a eventos com SQS e SNS. Com isso em mente, vamos substituir os elementos do nosso diagrama alto nível pelos serviços AWS.
Sei que esse novo diagrama parece assustador, mas se você reparar bem, ele tem as mesmas partes que o último diagrama, apenas trazido para o universo AWS.
Para a parte da aplicação que os clientes e cozinheiros acessam, vamos criar duas aplicações web separadas deployadas com AWS Amplify , um serviço que nos ajuda na criação, deploy e hospedagem de aplicações frontend conectadas a serviços AWS. Cada uma dessas interfaces vai se conectar com seu próprio backend hospedado em uma função Lambda. Essa conexão é feita através de uma API usando Amazon API Gateway.
Repare que estamos usando a mesma API para a interface dos clientes e dos cozinheiros. Tomei essa decisão pois as duas estão sendo criadas e mantidas pela mesma pessoa (eu) e acessam a mesma base de dados através do Amazon DynamoDB.
Já para a parte assíncrona da nossa aplicação, temos uma lambda responsável por gerar as notas fiscais e outra responsável por otimizar as rotas de entrega e escolher o melhor entregador para o pedido. As duas lambdas são acionadas a partir do mesmo evento de um novo pedido sendo criado. Por esse motivo, ambas consomem do mesmo tópico SNS. Poderíamos ter conectado as Lambdas diretamente ao tópico, mas optei por adicionar uma fila SQS entre o tópico e as Lambdas para que a fila sirva como buffer para as mensagens. Além disso, o uso da fila nos permite conectar uma Dead Letter Queue (DLQ). Essa é uma fila auxiliar para onde as mensagens que não são processadas corretamente são enviadas.
Por último, conectei a lambda que gera rotas e seleciona o entregador a um tópico SNS que notifica o entregador por mensagem. A Lambda de rotas já tem as informações da rota e do entregador, então não achei necessário criar outra Lambda para esse envio, simplificando nosso sistema.
Conclusão e próximos passos
Vimos que serverless na AWS é muito mais do que Lambda. O Amazon API Gateway nos dá a porta de entrada pra comunicação síncrona com clientes externos, enquanto SNS e SQS nos permitem orquestrar comunicação assíncrona entre partes do sistema. Com essas três peças trabalhando juntas, dá pra montar arquiteturas resilientes, escaláveis e econômicas, como vimos no exemplo da pizzaria.
Agora é a sua vez de colocar a mão na massa. Pegue um sistema que você queira construir, pense em quais comunicações precisam ser síncronas e quais podem ser assíncronas, e desenhe a arquitetura usando os serviços que vimos aqui. A melhor forma de fixar esses conceitos é desenhando seus próprios sistemas e quebrando a cabeça com as decisões.
Se quiser ir além, crie uma conta Free Tier e tente reproduzir o sistema que construímos por aqui. E me conta nos comentários, qual sistema você está com vontade de construir? Até a próxima!
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article