Diagrama de arquitetura serverless na AWS: API Gateway, Lambda, DynamoDB e eventos

Em um sistema serverless os servidores somem, e com eles a forma habitual de um diagrama de arquitetura. O que importa passa a ser como cada função é acionada, o que acontece quando ela falha e quais eventos ligam uma parte do sistema à próxima. Um diagrama com vinte caixas de Lambda e nenhum gatilho parece completo e não explica nada.

Este guia mostra como desenhar um diagrama de arquitetura serverless na AWS que uma pessoa nova no time consiga acompanhar: um exemplo completo, uma notação para tipos de invocação e caminhos de falha, e os erros que tornam esses diagramas enganosos.

Comece por como cada função é invocada

Toda função Lambda no diagrama é iniciada por alguma coisa, e a AWS tem três modelos de invocação, que se comportam de forma diferente quando algo dá errado. Essa é a informação mais útil que um diagrama serverless pode mostrar.

Modelo de invocação	Origens típicas	Quem tenta de novo em caso de falha	Onde as falhas vão parar
Síncrono	API Gateway, uma URL de função, uma chamada de SDK	Quem chama decide	Uma resposta de erro para quem chamou
Assíncrono	EventBridge, notificações do S3, SNS	O Lambda tenta de novo duas vezes por padrão	Um destino em caso de falha ou uma fila de mensagens mortas (DLQ), se você configurar um
Mapeamento da origem do evento (o Lambda faz polling)	SQS, DynamoDB Streams, Kinesis	O Lambda continua tentando o lote de novo	SQS: a fila de mensagens mortas da fila. Streams: um destino em caso de falha, ou os registros expiram

Rotule a conexão de cada gatilho com a origem e o modelo: sync, async ou poll, batch 10. Quando um incidente começa com "as mensagens estão se acumulando", essa é a linha que todo mundo procura.

O exemplo: uma API de pedidos serverless

Um pequeno serviço de pedidos construído inteiramente sobre serviços gerenciados:

1. Os clientes chamam uma API HTTP do API Gateway. Um autorizador JWT verifica os tokens emitidos por um grupo de usuários do Amazon Cognito.
2. O API Gateway invoca createOrder de forma síncrona. A função valida a requisição e grava o pedido na tabela orders do DynamoDB.
3. Um stream do DynamoDB na tabela aciona publishOrderEvents, que envia OrderPlaced para um barramento personalizado do EventBridge. Como o evento vem do stream, ele só é publicado para gravações que deram certo.
4. Uma regra do EventBridge captura OrderPlaced e o envia para a fila SQS receipts.
5. O Lambda faz polling da fila e invoca sendReceipt com lotes de até dez mensagens; a função envia um e-mail ao cliente pelo Amazon SES.
6. Uma mensagem que falha cinco vezes vai para receipts-dlq, onde um alarme avisa o time.

O caminho da requisição termina no passo 2: o cliente recebe a resposta assim que o pedido é armazenado. Tudo o que vem depois é assíncrono, e o diagrama desenha esses gatilhos com conexões tracejadas.

Regras para diagramas serverless

Desenhe os gatilhos como conexões rotuladas

A conexão que entra em uma função diz o que a inicia: POST /orders, DynamoDB stream, rule: OrderPlaced, SQS, batch 10. Uma função sem conexão de entrada é código morto ou uma linha que falta no seu diagrama.

Separe o caminho da requisição do trabalho assíncrono

Use conexões contínuas para chamadas síncronas e tracejadas para tudo o que acontece depois. Quem lê o diagrama precisa conseguir seguir o caminho que adiciona latência para o usuário sem ler cada rótulo.

Desenhe o caminho de falha de propósito

Para cada conexão assíncrona, decida para onde vão as falhas e desenhe isso: uma fila de mensagens mortas, um destino em caso de falha ou uma nota dizendo "os registros expiram após 24 horas". O DynamoDB Streams guarda os registros por 24 horas, então um consumidor que continua falhando perde eventos quando eles expiram. Um destino em caso de falha no S3 guarda uma cópia dos registros que falharam; um destino SQS ou SNS recebe só metadados, então alguma coisa precisa ler os registros de volta do stream dentro dessas 24 horas.

Uma função por nó

Um único nó "Lambda" para trinta funções esconde os gatilhos, e os gatilhos são a arquitetura. Se houver funções demais, divida o diagrama por serviço em vez de juntar caixas.

Agrupe em frames por unidade de implantação

Agrupe em um frame os recursos que são implantados juntos, como uma stack do SAM, do CDK ou do Terraform. Isso mostra quem é dono do quê e o que muda junto.

Registre permissões e limites em notas

Toda função tem uma role de execução do IAM, e algumas têm simultaneidade reservada ou timeouts longos. Não desenhe uma role por função. Adicione uma nota com o que importa numa revisão: "só createOrder pode gravar em orders", "gatilho SQS de sendReceipt com simultaneidade máxima 5 para proteger os limites do SES".

Erros comuns

• API Gateway desenhado como balanceador de carga. Ele também autentica, limita a taxa e transforma requisições, e o autorizador deve aparecer no diagrama.
• Filas de mensagens mortas ausentes, ou filas de mensagens mortas que ninguém monitora. Desenhe o alarme também.
• Barramentos de eventos sem regras. Um barramento do EventBridge distribui eventos por regra; rotule a conexão com a regra, não só com o barramento.
• Nenhuma distinção entre sync e async. É a diferença entre uma API lenta e um e-mail lento.
• Ruído de infraestrutura. Grupos de logs, camadas e cada política do IAM ficam no template, não na visão geral.

Monte o diagrama no Archboard

Os nós do pack Nuvem do Archboard são neutros em relação ao provedor e têm portas, então você rotula cada nó com o nome do serviço da AWS:

1. Entre com Google ou GitHub e crie um diagrama.
2. Adicione nós Caixa do pack Básico para os clientes e para o Amazon SES, um Gateway de API do pack Nuvem e um Provedor de identidade do pack Segurança com o rótulo Amazon Cognito.
3. Adicione uma Função do pack Nuvem para cada função Lambda, com o nome exatamente igual ao do seu template.
4. Adicione um Banco de dados gerenciado do pack Nuvem com o rótulo DynamoDB: orders, um Tópico do pack Dados com o rótulo EventBridge bus, nós Fila do pack Nuvem para a fila e sua fila de mensagens mortas, e um Alerta do pack DevOps para o alarme.
5. Conecte as portas. Mantenha o caminho da requisição com linha contínua, mude as conexões assíncronas para tracejadas e rotule cada gatilho com a origem e o modelo de invocação.
6. Coloque a stack em uma Moldura do pack Básico, adicione notas sobre permissões e limites e depois compartilhe o link ao vivo com o time.

O exemplo usa 13 nós de diagrama, o que cabe no plano Free. Para a rede em torno de uma carga de trabalho serverless ou de contêineres, veja o guia de diagrama de VPC da AWS e, para mais padrões de nuvem, a página de casos de uso de nuvem.

Perguntas frequentes

Devo desenhar cada função Lambda? No diagrama do serviço, sim, porque cada uma tem seu próprio gatilho e seu próprio comportamento em caso de falha. Numa visão geral do sistema, mostre o serviço como um único nó e coloque um link para o diagrama dele.

Posso usar os ícones oficiais da AWS? O Archboard não tem um pack específico da AWS: monte o diagrama com nós tipados e com portas dos packs Nuvem, Rede e Segurança, e rotule cada um com o nome do serviço, como Amazon SES ou DynamoDB: orders. Se você também quiser logos, Pesquisar e inserir tem ícones de marca para serviços da AWS, como o AWS Lambda, que você pode posicionar como nós de ícone.

Como mostro o Step Functions? Como um único nó no diagrama de arquitetura, rotulado com o nome da máquina de estado, e o fluxo de trabalho em si como um fluxograma ou diagrama BPMN separado.

Onde entram cold starts e simultaneidade? Em notas ao lado das funções em que eles importam, por exemplo a simultaneidade provisionada em um endpoint sensível à latência.

Preciso mostrar as roles do IAM? Não como nós. Anote as permissões que moldam o design e mantenha as políticas completas no seu código de infraestrutura.

Comece grátis — um assento, sem cartão de crédito.