Go Ahead — Backends modernos em Go

Vamos juntar as peças que você já conhece e seguir o caminho de UMA requisição HTTP, do dedo do usuário que clicou em "Comprar" até o byte salvo no banco. Entender esse fluxo é o que diferencia quem "sabe AWS" de quem só decorou nomes de serviços.

Cenário — O e-commerce "Loja do João"

João tem um e-commerce de cafés especiais. Quando um cliente clica em "Finalizar pedido", a requisição percorre o seguinte caminho:

Passo 1 — DNS (Route 53)

O navegador do cliente precisa descobrir qual o IP de loja-do-joao.com.br. Ele consulta o Route 53 (DNS gerenciado da AWS), que responde com o IP do Load Balancer. Esse passo leva milissegundos e já conta com cache do navegador e do provedor de internet.

Passo 2 — CDN (CloudFront) — opcional, mas recomendado

Antes de bater no Load Balancer, a requisição pode passar pelo CloudFront, a CDN da AWS. Se for um arquivo estático (imagem do produto, CSS), ele é servido direto do edge location mais próximo do cliente, sem ir até o servidor. Cliente em Belo Horizonte pega imagem em um servidor em Belo Horizonte. Latência despenca.

Passo 3 — Load Balancer (ALB)

Para requisições dinâmicas (POST /pedido, GET /carrinho), a CDN deixa passar e a requisição chega no ALB. O ALB faz três coisas:

Termina a conexão HTTPS (TLS handshake e descriptografia)
Verifica saúde das instâncias do backend (health check)
Escolhe uma instância saudável e encaminha a requisição

Passo 4 — Backend (EC2 / ECS / Lambda)

A instância EC2 (ou container no ECS, ou função Lambda) recebe a requisição. O código da aplicação roda: valida o pedido, calcula frete, aplica desconto.

Passo 5 — Banco de dados (RDS)

A aplicação precisa salvar o pedido. Ela abre uma conexão com o RDS PostgreSQL, executa um INSERT na tabela pedidos. Como o RDS é Multi-AZ, o dado é gravado também na réplica em outra AZ antes de o INSERT retornar (commit síncrono).

Passo 6 — Armazenamento (S3)

Se o cliente subiu um comprovante de pagamento, a aplicação envia o arquivo para um bucket S3. O S3 retorna a URL e a aplicação salva essa URL no banco junto ao pedido.

Passo 7 — Filas e processamento assíncrono (SQS / SNS)

O pedido foi salvo, mas tem coisas que não precisam acontecer agora: enviar email de confirmação, gerar nota fiscal, notificar a transportadora. A aplicação publica uma mensagem em uma fila SQS. Um worker (outra EC2 ou Lambda) consome a fila e processa cada item, sem fazer o cliente esperar.

Passo 8 — Resposta

A aplicação retorna um JSON com {status: "ok", pedidoId: 12345}. A resposta volta pelo ALB, eventualmente pela CDN, e chega no navegador do cliente, que mostra a tela "Pedido confirmado".

Diagrama mental do fluxo

flowchart TD
  U[Usuário] --> DNS["DNS — Route 53"]
  DNS --> CDN["CDN — CloudFront"]
  CDN --> ALB["Load Balancer — ALB"]
  ALB --> EC2a["EC2 — AZ-a"]
  ALB --> EC2b["EC2 — AZ-b"]
  EC2a & EC2b --> RDSp["RDS Primary — AZ-a"]
  RDSp -.-|"réplica"| RDSs["RDS Standby — AZ-b"]
  RDSp --> S3["S3 / SQS / Cache"]

Esse fluxo pode parecer muita coisa, mas é o padrão da indústria. Você não precisa montar tudo no primeiro dia. Comece simples (1 EC2 + 1 RDS) e vá adicionando peças conforme a aplicação cresce. Conhecer o fluxo completo te ajuda a saber ONDE adicionar a próxima peça quando precisar escalar.

VPC — A casa onde tudo isso mora

Tudo o que descrevemos roda dentro de uma VPC (Virtual Private Cloud), que é a sua rede privada na AWS. Pense nela como o terreno cercado da empresa.

Dentro da VPC você tem subnets:

Subnets públicas: recebem IP público, acessíveis pela internet. ALB e NAT Gateway moram aqui.
Subnets privadas: sem IP público. EC2 de aplicação, RDS e ElastiCache moram aqui. Acessam internet (para baixar pacotes) via NAT Gateway.

Sempre coloque banco de dados, cache e backend interno em subnets PRIVADAS. Só o Load Balancer fica em subnet pública. Isso reduz drasticamente sua superfície de ataque.

Como uma aplicação roda na AWS