# Computação em nuvem explicada: os 11 conceitos de arquitetura que você deve conhecer (Masterclass 4K).

Published: 2026-09-15

A maioria dos engenheiros de software tenta aprender arquitetura de nuvem memorizando centenas de siglas de produtos de fornecedores em AWS, GCP e Azure. Mas a engenharia de nuvem do mundo real é construída em onze primitivos arquitetônicos fundamentais. Nesta masterclass remasterizada em 4K, Niko detalha o plano empresarial completo: desde dimensionamento vertical versus horizontal e balanceamento de carga da Camada 7 até dimensionamento automático dinâmico, execução de microVMs sem servidor, desacoplamento assíncrono orientado a eventos, orquestração de contêineres, a hierarquia de armazenamento de quatro pilares, a diferença crítica entre alta disponibilidade e 11 noves de durabilidade, Infraestrutura como Código declarativa e rede de Virtual Private Cloud. Domine esses onze conceitos e você poderá projetar qualquer back-end em produção. Veredito: SHIP IT.

Canonical: https://thedailydiff.dev/pt-PT/video/2026-09-14-cloud-computing-explained-4k/

## O que este vídeo aborda

- - A Parede da Arquitetura e o Plano Mestre
- - 01. Dimensionamento Vertical vs. Horizontal
- - 02. Arquitetura de Balanceamento de Carga (L4 vs. L7 e Verificações de Saúde)
- - 03. Dimensionamento Automático e Elasticidade
- - 04. Sem Servidor (FaaS e Firecracker MicroVMs)

## Capítulos

- 0:00 - A Parede da Arquitetura e o Plano Mestre
- 0:57 - 01. Dimensionamento Vertical vs. Horizontal
- 2:17 - 02. Arquitetura de Balanceamento de Carga (L4 vs. L7 e Verificações de Saúde)
- 3:45 - 03. Dimensionamento Automático e Elasticidade
- 4:50 - 04. Sem Servidor (FaaS e Firecracker MicroVMs)
- 6:05 - 05. Arquitetura Orientada a Eventos (EDA e Desacoplamento)
- 7:13 - 06. Orquestração de Contêineres (Docker e Kubernetes)
- 8:16 - 07. Os 4 Pilares do Armazenamento em Nuvem (S3, EBS, DBs e Redis)
- 9:44 - 08. Alta Disponibilidade e os Noves (Failover Multi-AZ)
- 10:53 - 09. Durabilidade vs. Disponibilidade (Por que 11 Noves Não é Tempo de Atividade)
- 12:14 - 10. Infraestrutura como Código (Terraform vs. Console Drift)
- 13:20 - 11. Rede em Nuvem (VPC, Sub-redes, NAT e Grupos de Segurança)
- 14:26 - 12. O Plano Empresarial Completo e Veredito

## Transcrição traduzida

Traduzido da narração original em inglês. Áudio e legendas disponíveis são controlados pelo YouTube.

### - A Parede da Arquitetura e o Plano Mestre

0:00 Todo engenheiro de software acaba enfrentando a parede da arquitetura em nuvem. Você constrói uma aplicação no seu laptop, a coloca em produção, e no momento em que usuários reais chegam, os servidores travam, as conexões do banco de dados se esgotam, e sua fatura da AWS parece um número de telefone. A maioria dos desenvolvedores tenta resolver a engenharia em nuvem memorizando trezentas siglas de produtos diferentes da AWS. Mas a computação em nuvem real não é sobre memorizar catálogos de fornecedores: ela é construída sobre onze primitivas arquitetônicas fundamentais.

0:34 Nesta masterclass, vamos percorrer todo o plano empresarial: desde dimensionamento e balanceamento de carga até sem servidor, desacoplamento orientado a eventos, hierarquias de armazenamento e rede em nuvem. Domine esses onze conceitos e você poderá projetar qualquer back-end na AWS, GCP ou Azure. Este é o The Daily Diff, nos bastidores.

### - 01. Dimensionamento Vertical vs. Horizontal

0:57 Conceito número um: Dimensionamento. Quando sua aplicação experimenta crescimento de tráfego, você tem duas maneiras fundamentalmente diferentes de lidar com a carga: dimensionamento vertical ou dimensionamento horizontal. Dimensionamento vertical, ou escalonamento, significa pegar sua máquina existente e adicionar mais recursos: atualizar de quatro núcleos de CPU para trinta e dois, ou trocar trinta e dois gigabytes de RAM por cento e vinte e oito. O dimensionamento vertical não exige alterações arquitetônicas: seu código

1:28 e banco de dados permanecem exatamente os mesmos. Mas atinge um teto de hardware brutal. Nenhuma máquina no mundo tem dez mil núcleos de CPU, e as instâncias de ponta têm um prêmio de preço exponencial. Dimensionamento horizontal, ou escalonamento, significa manter seus servidores pequenos e com preço de commodity, mas executar várias instâncias em paralelo atrás de um roteador. Se uma instância falhar, os nós restantes absorvem o tráfego com zero tempo de inatividade. A regra de ouro do dimensionamento horizontal é

2:01 a ausência de estado: seus servidores de aplicação não podem armazenar sessões de usuário, arquivos carregados ou estado em seus discos locais. O estado deve residir em um banco de dados externo ou cache, permitindo que qualquer nó processe qualquer solicitação do usuário.

### - 02. Arquitetura de Balanceamento de Carga (L4 vs. L7 e Verificações de Saúde)

2:17 Conceito número dois: Balanceamento de Carga. O dimensionamento horizontal parece ótimo no papel, mas introduz um problema imediato: quando dez mil usuários acessam seu nome de domínio, qual servidor específico recebe o tráfego deles? Um balanceador de carga atua como um proxy reverso situado entre a internet pública e seu cluster de back-end privado. Ele aceita conexões TCP ou HTTP de entrada e distribui as solicitações entre suas instâncias saudáveis.

2:47 Os balanceadores de carga operam em duas camadas de rede primárias. Os Balanceadores de Carga de Rede da Camada 4 operam na camada de transporte, roteando pacotes TCP e UDP brutos com base no endereço IP e porta com latência de microssegundos e milhões de solicitações por segundo. Os Balanceadores de Carga de Aplicação da Camada 7 inspecionam o protocolo HTTP em si: lendo caminhos de URL, cabeçalhos de solicitação, cookies e métodos HTTP. Isso permite o roteamento baseado em caminho: enviando solicitações "slash-api" para o seu cluster de back-end e solicitações "slash-static" para um

3:25 armazenamento de objetos. Crucialmente, os balanceadores de carga realizam verificações de saúde ativas. A cada poucos segundos, o balanceador envia um ping para um endpoint de saúde em cada instância. Se uma instância lançar três erros consecutivos de quinhentos ou não responder, ela é automaticamente removida do pool com zero solicitações perdidas.

### - 03. Dimensionamento Automático e Elasticidade

3:45 Conceito número três: Dimensionamento Automático. Se sua aplicação web precisa de dois servidores às três da manhã, mas vinte servidores durante um lançamento ao meio-dia, clicar manualmente em botões no console da nuvem é um caminho garantido para tempo de inatividade e falência. O dimensionamento automático traz elasticidade dinâmica para pools de servidores horizontais. Um Grupo de Dimensionamento Automático monitora métricas de desempenho como utilização média da CPU, E/S de rede ou profundidade do backlog da fila. Quando a CPU média ultrapassa um limite definido — digamos,

4:19 setenta por cento por três minutos consecutivos — o dimensionador automático automaticamente lança novas máquinas virtuais, as registra com seu balanceador de carga, e começa a rotear o tráfego. Igualmente importante é o dimensionamento de entrada: quando a onda de tráfego diminui, o dimensionador automático encerra instâncias em excesso para que você pare de pagar por computação ociosa. Para evitar flapping — onde os servidores são rapidamente criados e destruídos em um loop interminável — os arquitetos de nuvem configuram períodos de resfriamento. Conceito número quatro: Sem servidor.

### - 04. Sem Servidor (FaaS e Firecracker MicroVMs)

4:53 Por anos, equipes de marketing apresentaram o serverless como um código mágico rodando no céu. Na realidade, o serverless ainda usa servidores — mas você não os possui, remenda ou paga por eles quando nenhum código está em execução. Com Function-as-a-Service como AWS Lambda ou Google Cloud Functions, você escreve uma função de manipulador autônoma. Quando ocorre uma solicitação HTTP, upload de arquivo S3 ou alteração no banco de dados, o tempo de execução da nuvem inicializa uma

5:23 micro-máquina-virtual efêmera como o Firecracker em menos de cinco milissegundos. Seu código é executado, retorna uma resposta e é encerrado. Se ninguém visitar seu site por três meses, sua fatura de computação será exatamente zero dólares e zero cêntimos. Se um milhão de usuários o acessarem simultaneamente, o provedor irá iniciar um milhão de microVMs concorrentes. As compensações de engenharia são reais: latência de inicialização a frio ao iniciar novos tempos de execução, um limite rígido de quinze minutos de execução no Lambda e estrita ausência de estado.

5:55 O serverless é imbatível para pipelines de eventos e APIs esporádicas, mas ruim para WebSockets persistentes ou execuções de treinamento de várias horas.

### - 05. Arquitetura Orientada a Eventos (EDA e Desacoplamento)

6:05 Conceito número cinco: Arquitetura Orientada a Eventos, ou EDA. Em arquiteturas tradicionais, os serviços comunicam-se de forma síncrona. Seu serviço de checkout chama o pagamento, o pagamento chama o estoque, o estoque chama a fraude e a fraude chama o e-mail. Isso cria a cascata síncrona da perdição. Se o provedor de e-mail de terceiros tiver um problema de rede e levar dez segundos para responder, a solicitação de checkout completa do seu cliente expirará com um erro. Em uma arquitetura orientada a eventos, os serviços são completamente desacoplados.

6:37 Quando um cliente clica em comprar, o serviço de checkout não chama os serviços downstream. Ele simplesmente publica um evento chamado OrderPlaced em um Barramento de Eventos central como o Amazon EventBridge ou um tópico SNS. O checkout é concluído em cinquenta milissegundos. Trabalhadores downstream para pagamento, dedução de estoque e recibos por e-mail extraem mensagens independentemente de suas próprias filas SQS dedicadas. Se o serviço de e-mail ficar inativo por uma hora, as mensagens aguardam com segurança armazenadas em buffer na fila sem uma única ordem perdida.

### - 06. Orquestração de Contêineres (Docker e Kubernetes)

7:13 Conceito número seis: Orquestração de Contêineres. O Docker resolveu o empacotamento: ele envolve o código da sua aplicação, bibliotecas de sistema, configuração e tempo de execução em uma imagem imutável que roda identicamente no seu MacBook e na nuvem. Mas empacotar um contêiner é fácil. Executar quinhentos contêineres em cinquenta máquinas virtuais físicas é onde a engenharia falha. É por isso que existem orquestradores de contêineres como Kubernetes e AWS ECS.

7:41 Um orquestrador fornece um plano de controle: um servidor API, um armazenamento de estado etcd e um agendador inteligente. Você declara seu estado desejado: quero dez réplicas do meu serviço de autenticação com dois gigabytes de RAM cada. O agendador inspeciona o cluster, aloca pods em nós com memória livre, configura a rede interna e reconcilia continuamente a realidade. Se um nó sofrer uma falha de hardware, o Kubernetes detecta a perda e reagenda instantaneamente todos os pods desalojados para

### - 07. Os 4 Pilares do Armazenamento em Nuvem (S3, EBS, DBs e Redis)

8:16 nós saudáveis. Conceito número sete: A Hierarquia de Armazenamento na Nuvem. Iniciantes frequentemente tratam o armazenamento em nuvem como um único balde onde se despejam arquivos. Em arquitetura de produção, o armazenamento é dividido em quatro pilares distintos com base em padrões de acesso e latência. Primeiro é o Armazenamento de Objetos, como Amazon S3 ou Google Cloud Storage. Você acessa arquivos através de APIs REST HTTP usando chamadas simples PUT e GET. Ele oferece capacidade horizontal infinita a dois cêntimos por gigabyte por mês,

8:49 tornando-o ideal para vídeo, uploads de usuários, logs e backups. Segundo é o Armazenamento em Bloco, como o Amazon EBS. São discos rígidos virtuais montados diretamente em uma máquina virtual específica através de interconexões de alta velocidade. Eles formatam em sistemas de arquivos padrão como ext4, suportando acesso rápido de leitura e escrita aleatória exigido por motores de banco de dados. Terceiro são Bancos de Dados Gerenciados: motores relacionais como PostgreSQL no RDS fornecendo transações ACID e junções complexas,

9:21 e motores NoSQL como DynamoDB entregando latência de um único dígito milissegundo em escala massiva. E quarto são Caches em Memória como o Redis. Ler dados da RAM leva microssegundos em vez de milissegundos. Os caches ficam na frente do seu banco de dados, protegendo-o do tráfego de leitura repetido e gerenciando tokens de sessão de usuário voláteis.

### - 08. Alta Disponibilidade e os Noves (Failover Multi-AZ)

9:44 Conceito número oito: Alta Disponibilidade, ou HA. A disponibilidade responde a uma pergunta: que percentagem do tempo sua aplicação está operacional e acessível pelos usuários? Em contratos empresariais, a disponibilidade é medida em noves. Dois noves, ou noventa e nove por cento de disponibilidade, permite mais de três e meio dias de tempo de inatividade por ano. Quatro noves reduzem o tempo de inatividade permitido para cinquenta e dois minutos, e cinco noves permitem apenas cinco minutos de tempo de inatividade total por

10:15 ano. Para alcançar alta disponibilidade, você deve eliminar pontos únicos de falha em domínios de falha. Na nuvem, isso significa implantar em várias Zonas de Disponibilidade. Uma Zona de Disponibilidade não é um único rack: é um ou mais distintos centros de dados físicos a quilómetros de distância com energia e refrigeração independentes. Ao executar instâncias ativas na Zona A e na Zona B com replicação de banco de dados síncrona, um raio ou corte de fibra que derrube uma instalação física inteira resulta em um failover automatizado

10:50 em trinta segundos, com zero intervenção humana.

### - 09. Durabilidade vs. Disponibilidade (Por que 11 Noves Não é Tempo de Atividade)

10:53 Conceito número nove: Durabilidade versus Disponibilidade. Esta é a armadilha conceptual mais comum nas entrevistas de arquitetura na cloud. Os engenheiros frequentemente usam as palavras de forma intermutável, mas medem propriedades completamente diferentes. Disponibilidade mede o tempo de atividade: posso fazer uma chamada de API para ler ou escrever os meus dados neste exato segundo? Durabilidade mede a preservação: os meus dados sobreviverão sem bit rot, corrupção ou destruição permanente ao longo de dez anos? Durabilidade mede a preservação: os meus dados sobreviverão sem bit rot, corrupção ou destruição permanente ao longo de dez anos? Durabilidade mede a preservação: os meus dados sobreviverão sem bit rot, corrupção ou destruição permanente ao longo de dez anos?

11:24 Veja o Amazon S3 Standard. O seu Acordo de Nível de Serviço oferece noventa e nove vírgula nove por cento de disponibilidade, o que permite cerca de quarenta e três minutos de tempo de inatividade por mês, onde um pedido de API pode retornar um erro quinhentos. onde um pedido de API pode retornar um erro quinhentos. Mas o S3 promete onze noves de durabilidade: noventa e nove vírgula nove nove nove nove nove nove nove nove nove por cento. Se armazenar dez milhões de ficheiros no S3, pode estatisticamente esperar perder em média um ficheiro a cada dez mil anos.

11:56 Se armazenar dez milhões de ficheiros no S3, pode estatisticamente esperar perder em média um ficheiro a cada dez mil anos. O S3 consegue isto através da codificação de objetos por eliminação e da replicação de blocos em pelo menos três instalações de dados geograficamente separadas. O S3 consegue isto através da codificação de objetos por eliminação e da replicação de blocos em pelo menos três instalações de dados geograficamente separadas. Durante uma grande interrupção de rede regional, o S3 pode estar temporariamente indisponível, mas os seus dados nunca são destruídos.

### - 10. Infraestrutura como Código (Terraform vs. Console Drift)

12:14 Conceito número dez: Infraestrutura como Código, ou IaC. Nos primeiros dias da computação em nuvem, os engenheiros entravam na consola de gestão web da AWS e clicavam manualmente para criar máquinas virtuais, configurar sub-redes e anexar grupos de segurança. e clicavam manualmente para criar máquinas virtuais, configurar sub-redes e anexar grupos de segurança. A indústria chama a isto ClickOps, e em produção, é um desastre absoluto. As alterações manuais na consola não têm trilha de auditoria, nenhum mecanismo de rollback, e inevitavelmente causam desvio de configuração entre os ambientes de staging e produção. Com ferramentas de Infraestrutura como Código e inevitavelmente causam desvio de configuração entre os ambientes de staging e produção. Com ferramentas de Infraestrutura

12:48 como Código, como Terraform, OpenTofu, Pulumi ou AWS CDK, define a sua como Código, como Terraform, OpenTofu, Pulumi ou AWS CDK, define a sua arquitetura de nuvem completa em arquivos de configuração declarativos armazenados no Git. Cada alteração a uma porta aberta ou réplica de base de dados passa por um pedido pull e revisão por pares. pedido pull e revisão por pares. Executar o plano do terraform pré-visualiza a diferença exata da API antes que algo seja alterado, e levantar uma réplica idêntica da sua stack de produção leva quatro minutos em vez de quatro semanas.

### - 11. Rede em Nuvem (VPC, Sub-redes, NAT e Grupos de Segurança)

13:20 Conceito número onze: Rede na Nuvem e Nuvens Privadas Virtuais. Quando implementa servidores na nuvem, eles não ficam expostos na internet pública. Eles vivem dentro de um limite isolado definido por software chamado VPC. Eles vivem dentro de um limite isolado definido por software chamado VPC. Dentro da sua VPC, você aloca um espaço de endereço IP privado como dez-ponto-zero-ponto-zero-ponto-zero barra dezasseis, e o divide em sub-redes públicas e privadas. Uma sub-rede pública tem uma rota direta para um Gateway de Internet.

13:51 Contém ativos voltados para o público, como os seus Balanceadores de Carga de Aplicação e Gateways NAT. É a única parte da sua rede que possui endereços IP públicos. Os seus servidores de aplicação e bases de dados de produção vivem estritamente em sub-redes privadas sem IPs públicos e zero rotas de entrada da internet. Quando os seus servidores de backend precisam descarregar atualizações de segurança, o tráfego de saída deles é roteado através do Gateway NAT na sub-rede pública. A rodear cada instância estão os Grupos de Segurança: firewalls virtuais com estado que aplicam o princípio do privilégio mínimo. A rodear cada instância estão os Grupos de Segurança: firewalls virtuais com estado que aplicam o princípio do privilégio mínimo.

### - 12. O Plano Empresarial Completo e Veredito

14:28 O seu grupo de segurança de base de dados só aceita conexões na porta 5432 estritamente do grupo de segurança dos seus servidores de aplicação, O seu grupo de segurança de base de dados só aceita conexões na porta 5432 estritamente do grupo de segurança dos seus servidores de aplicação, tornando a penetração externa matematicamente impossível. Ao expandir a visão, estes onze primitivos conectam-se num sistema coeso. O seu DNS direciona para um Balanceador de Carga numa sub-rede pública, grupos de autoescalamento gerem picos de tráfego em múltiplas Zonas de Disponibilidade, barramentos de eventos desacoplam trabalhadores de backend, e toda a sua stack é implementada a partir do Git usando Infraestrutura como Código.

15:02 Veredito da masterclass de hoje: SHIP IT. Pare de memorizar centenas de acrónimos de marketing da cloud. Domine estes onze padrões de arquitetura, desacople o seu estado, e construa sistemas que não podem falhar. Diga-me qual conceito de cloud lhe deu a maior dor de cabeça quando começou a construir nos comentários. Diga-me qual conceito de cloud lhe deu a maior dor de cabeça quando começou a construir nos comentários. E para obter a folha de dicas completa de arquitetura, subscreva a newsletter em the daily diff dot dev, link abaixo.

15:28 E subscreva a newsletter em the daily diff dot dev, link abaixo. E essa é a diferença de hoje. Eu sou o Niko da Axrisi. Faça o merge de forma responsável.

## Fontes

- [AWS Well-Architected Framework (Reliability & Performance Pillars)](https://aws.amazon.com/architecture/well-architected/) — aws.amazon.com
- [Kubernetes Architecture & Control Plane Concepts](https://kubernetes.io/docs/concepts/architecture/) — kubernetes.io
- [Martin Fowler: What is Event-Driven Architecture?](https://martinfowler.com/articles/201701-event-driven.html) — martinfowler.com
- [Amazon S3 Data Durability & Availability Technical Whitepaper](https://aws.amazon.com/s3/features/) — aws.amazon.com
- [HashiCorp: Declarative Infrastructure as Code with Terraform](https://www.terraform.io/) — www.terraform.io