3.5 Escalabilidade, desempenho e resiliência

Visão geral e motivação

A escalabilidade, o desempenho e a resiliência são três qualidades distintas, e as pessoas costumam misturá-las. O desempenho é quão rápido o sistema responde e quanto trabalho ele faz por unidade de recurso. A escalabilidade é quão bem ele mantém o desempenho à medida que a carga cresce. A resiliência é quão bem ele continua funcionando, ou se degrada com elegância, quando as coisas falham. Um sistema pode ser rápido mas não escalável (ótimo com carga baixa, colapsa com carga alta), escalável mas frágil (aguenta volume mas cai quando um componente falha) ou resiliente mas lento. Uma grande organização precisa das três, projetadas desde o início, porque adaptar qualquer uma delas depois do lançamento é caro e perturbador.

Para sistemas corporativos e governamentais, as consequências de errar nisso são públicas e severas. Pense num portal de benefícios que cede no primeiro dia de um novo programa, num sistema de declaração de impostos que esgota o tempo no prazo final ou numa plataforma de pagamentos que cai durante o pico de compras. São as falhas que viram manchete, disparam inquéritos e corroem a confiança pública. Esses sistemas também enfrentam cargas muito concentradas e muitas vezes cronometradas por lei (prazos de declaração, janelas de inscrição, dias de pagamento) e obrigações rigorosas de disponibilidade e de recuperação. É preciso planejar a capacidade para os picos previsíveis, degradar com elegância sob os imprevisíveis e se recuperar dentro de limites definidos de tempo e de perda de dados depois de um desastre. Isso é engenharia com uma dimensão de prestação de contas pública.

Este capítulo cobre o escalamento horizontal versus o vertical, a ausência de estado e o sharding como habilitadores de escala, o balanceamento de carga, o escalamento automático e o planejamento de capacidade, a engenharia de desempenho com orçamentos explícitos, os padrões de resiliência e a engenharia do caos e a recuperação de desastres multirregional enquadrada por RTO, RPO e continuidade de negócio. A mensagem unificadora é que essas qualidades são produto de design deliberado e de teste contínuo, não de esperança.

Veja também: o capítulo 3.3 (sistemas distribuídos), o capítulo 9.1 (engenharia de confiabilidade de sites) e o capítulo 9.2 (observabilidade e monitoramento).

Princípios fundamentais

Projete para escalar para fora, não para cima. O escalamento vertical tem um teto e um ponto único de falha. O escalamento horizontal é como se chega a uma escala grande e resiliente.
A ausência de estado é o habilitador do escalamento horizontal. Se qualquer requisição pode ir a qualquer instância, você pode acrescentar e remover capacidade livremente.
Você não consegue melhorar o que não mede. O trabalho de desempenho é conduzido por profiling e teste de carga contra orçamentos explícitos, nunca por adivinhação.
Tudo falha. Projete para isso. Presuma que os componentes falharão e construa de modo que o sistema sobreviva à falha deles.
A degradação graciosa vence a falha dura. Um sistema parcialmente funcional que descarta funcionalidades não essenciais é melhor que uma queda total.
A capacidade é planejada, os picos são absorvidos. Preveja a carga previsível. Use escalamento automático e folga para o resto.
Os objetivos de recuperação são decisões de negócio. O RTO e o RPO são escolhidos pelo negócio contra o custo e depois trabalhados por engenharia.
Teste a resiliência deliberadamente. Você não sabe que um sistema é resiliente até tê-lo feito falhar de propósito.

Recomendações

Prefira o escalamento horizontal e projete serviços sem estado

O escalamento vertical (máquinas maiores) é simples e às vezes o primeiro passo certo, mas atinge um teto rígido, fica desproporcionalmente caro no topo e deixa um ponto único de falha. O escalamento horizontal (mais máquinas atrás de um balanceador de carga) escala muito mais longe e melhora a disponibilidade, porque perder uma instância é sobrevivível. O pré-requisito é a ausência de estado. Não guarde nenhuma sessão de cliente nem estado de requisição na instância. Empurre-os para um armazenamento compartilhado (banco de dados, cache, token). Serviços sem estado podem ser acrescentados, removidos, substituídos e balanceados livremente, o que torna possíveis tanto o escalamento automático quanto a implantação gradual. Onde o estado precisa ser particionado, faça sharding por uma chave que distribua a carga de forma uniforme e mantenha os dados relacionados no mesmo shard.

Balanceie a carga, escale automaticamente e planeje a capacidade

Ponha um balanceador de carga na frente de toda camada escalada para distribuir o tráfego e contornar instâncias não saudáveis por meio de verificações de saúde. Configure o escalamento automático para acrescentar capacidade quando um indicador antecedente (CPU, profundidade da fila de requisições, latência) cruza um limite e removê-la quando a carga cai. Ajuste a velocidade e os resfriamentos do escalamento para não ficar atrás de um pico nem oscilar. O escalamento automático não é um substituto para o planejamento de capacidade. Para picos previsíveis e críticos para o negócio (prazos de impostos, períodos de inscrição, eventos de vendas), preveja a carga, pré-provisione ou pré-aqueça a capacidade e faça testes de carga até essa meta com antecedência. O escalamento automático sozinho não consegue reagir instantaneamente a uma mudança em degrau, e as partidas a frio acrescentam latência exatamente quando você menos pode bancá-la. Mantenha sempre folga. Operar a 100% não deixa espaço para absorver picos nem falhas.

Projete o desempenho contra orçamentos explícitos

Defina orçamentos de desempenho (metas concretas como latência p95 da API abaixo de 200 ms, página interativa em menos de 2 segundos ou custo por transação abaixo de um limite) e imponha-os em testes e monitoramento para que as regressões quebrem o pipeline em vez de chegarem aos usuários. Conduza a otimização com medição. Faça profiling para encontrar o gargalo real, que raramente está onde você adivinha, e teste a carga para achar onde o sistema quebra e como se comporta perto desse limite. Concentre-se no caminho crítico e na cauda (p95/p99), porque em escala as latências de cauda dominam a experiência do usuário. Otimize primeiro o maior gargalo, meça de novo e pare quando atingir o orçamento. Superotimizar código já adequado é esforço desperdiçado.

Embuta padrões de resiliência e valide-os com engenharia do caos

Aplique os padrões de resiliência dos sistemas distribuídos: tempos limite, novas tentativas limitadas com recuo, disjuntores (que falham rápido quando uma dependência não está saudável) e anteparas (que isolam conjuntos de recursos para que uma falha não esgote o resto), mais a degradação graciosa (descartar ou simplificar funcionalidades não essenciais sob estresse: desligar recomendações, servir conteúdo em cache, pôr trabalho não urgente em fila) e o descarte de carga (rejeitar ou limitar o excesso de requisições para proteger o núcleo em vez de colapsar por inteiro). Elimine os pontos únicos de falha com redundância em todas as camadas. Depois valide a resiliência com a engenharia do caos. Injete falhas deliberadamente (derrubar instâncias, acrescentar latência, cortar uma dependência, derrubar uma zona) em experimentos controlados, começando em teste e amadurecendo até dias de simulação em produção, para provar que o sistema se comporta como projetado. A resiliência que nunca foi testada é apenas uma hipótese.

Planeje a multirregionalidade, a recuperação de desastres e a continuidade de negócio

Decida explicitamente os objetivos de recuperação: o RTO (Recovery Time Objective, quanto tempo você pode ficar fora do ar) e o RPO (Recovery Point Objective, quantos dados você pode se permitir perder). São decisões de negócio com implicações diretas de custo e conduzem a arquitetura. As opções variam em custo e velocidade: cópia e restauração (a mais barata, a mais lenta), luz piloto, espera morna e multirregional ativo-ativo (a mais cara, RTO/RPO próximos de zero). Escolha o nível que a criticidade de cada sistema justifica. Nem tudo precisa de ativo-ativo. Replique os dados entre regiões de modo consistente com o RPO escolhido, automatize o failover e, acima de tudo, teste o failover regularmente. A recuperação de desastres não testada falha de forma confiável quando finalmente se precisa dela. Envolva tudo isso num plano de continuidade de negócio que cubra pessoas, comunicações e alternativas manuais, não apenas tecnologia.

Compromissos: prós e contras

Escolha	Prós	Contras
Escalamento vertical	Simples, sem mudança de código, pouco esforço inicial	Teto rígido, caro no topo, ponto único de falha
Escalamento horizontal	Escala quase ilimitada, melhora a disponibilidade	Exige ausência de estado, balanceamento de carga, mais operação
Escalamento automático	Ajusta o custo à demanda, trata carga variável	Reage com atraso. Partidas a frio. Pode oscilar se mal ajustado
Multirregional ativo-ativo	RTO/RPO próximos de zero, sobrevive à perda de uma região	Maior custo e complexidade, consistência de dados difícil
Recuperação de desastres por cópia e restauração	A mais barata, a mais simples	RTO longo, janela maior de perda de dados

A troca central é custo versus garantia. Cada incremento de folga de escalabilidade, de desempenho e de capacidade de recuperação custa dinheiro e complexidade, e os retornos são não lineares. Passar de 99,9% para 99,99% de disponibilidade, ou de um RTO de uma hora para segundos, pode multiplicar o custo. A disciplina é dimensionar cada investimento à criticidade real do sistema e à tolerância do negócio a indisponibilidade e perda de dados, em vez de projetar tudo por reflexo para o nível mais alto. Um sistema de pagamentos voltado ao cidadão merece redundância ativo-ativo. Uma ferramenta interna de relatórios, não.

Perguntas para discutir com sua equipe

Quando aconteceu o seu último incidente grave, qual das três (desempenho, escalabilidade, resiliência) de fato falhou, e vocês corrigiram a certa? O capítulo as separa deliberadamente: um sistema pode ser rápido e ainda assim colapsar sob carga, escalar mas cair quando um componente morre ou sobreviver a falhas sendo lento. As equipes costumam diagnosticar errado, acrescentando capacidade a um problema de resiliência ou endurecendo um sistema que estava simplesmente subprovisionado para um pico. Percorram os dois últimos incidentes graves e nomeiem qual qualidade quebrou e o que a resposta de fato melhorou. A distinção muda a correção: ausência de estado e sharding para a escala, redundância e disjuntores para a resiliência, profiling e orçamentos para o desempenho. Acertar a categoria é a diferença entre gastar na cura e gastar num sintoma.
As regressões de desempenho quebram o seu pipeline, ou chegam aos usuários antes que alguém note? Um orçamento de desempenho (latência p95, tempo até a página ficar interativa, custo por transação) só protege os usuários se for imposto automaticamente, de modo que uma mudança que o estoure quebre o build em vez de ser entregue. Numa equipe grande com muitos contribuidores, a latência se infiltra por mil pequenos commits, e sem um portão a cauda apodrece devagar até um lançamento expô-la. Levem seus orçamentos atuais e verifiquem se estão ligados à CI e ao monitoramento e se miram o p95 e o p99 em vez de médias, porque a cauda é o que os usuários sentem em escala. Onde não existe orçamento, definir um é o primeiro movimento. A imposição é o que transforma uma boa intenção numa propriedade que sobrevive ao crescimento da equipe.
Sob estresse, o que é descartado primeiro, e vocês projetaram essa ordem ou vão descobri-la na queda? A degradação graciosa e o descarte de carga significam que o sistema abre mão do trabalho não essencial para proteger o núcleo, mas só se vocês decidiram de antemão o que é essencial. Para um serviço voltado ao cidadão essa classificação costuma ser uma decisão de política: enviar uma declaração de impostos precisa sobreviver mesmo que os painéis de status e as consultas históricas apaguem. Se ninguém escolheu, o sistema descarta o que falhar primeiro, que pode ser exatamente aquilo de que os usuários mais precisam. Listem suas funcionalidades em ordem de prioridade e confirmem que a arquitetura consegue largar as de baixa prioridade (respostas em cache, recomendações desligadas, trabalho não urgente em fila) sem levar junto o caminho crítico. Depois testem sob carga real, porque a degradação não testada é só uma esperança.
Para o seu sistema mais crítico, quais são o RTO e o RPO, quem de fato escolheu esses números e quando foi a última vez que vocês provaram que conseguem cumpri-los? O Recovery Time Objective (quanto tempo você pode ficar fora do ar) e o Recovery Point Objective (quantos dados você pode se permitir perder) são decisões de negócio com implicações diretas de custo, mas numa equipe grande costumam ser inventados por quem escreveu o runbook e não de propriedade das pessoas responsáveis pelo serviço. A atração concorrente é custo contra garantia: reduzir o RTO de uma hora para segundos, ou o RPO de minutos para zero, pode multiplicar a conta de infraestrutura, então o número certo é o que o negócio de fato pagará, não o mais impressionante. Levem os objetivos documentados, a data do último teste real de failover e o tempo e a perda de dados medidos que esse teste produziu, porque um objetivo não testado é um desejo. Em contextos corporativos e governamentais esses números podem ser fixados por lei, contrato ou SLA, então nomeiem quem os aprova e se o último ensaio cumpriu a obrigação ou a perdeu em silêncio.
Para o seu maior pico previsível, vocês confiam no escalamento automático para reagir na hora, ou previram a carga, pré-provisionaram e testaram a carga até essa meta? O escalamento automático reage com atraso e as partidas a frio acrescentam latência exatamente quando você menos pode bancá-la, então uma mudança em degrau conhecida (um prazo de declaração, uma janela de inscrição, um evento de vendas) é precisamente o caso em que o escalamento reativo falha e o planejamento deliberado de capacidade vence. A tensão é o custo: pré-aquecer capacidade para um pico significa pagar por folga que fica ociosa a maior parte do ano, e a tentação é esperar que o escalamento automático cubra de graça. Levem os números de pico do ano passado, a previsão deste ano com crescimento e os resultados de um teste de carga rodado até um múltiplo dessa previsão e não até o tráfego médio de hoje. Para um serviço governamental ou corporativo que enfrenta um pico cronometrado por lei, acrescentem a consequência de errar, já que um portal de benefícios ou um sistema tributário que cede no primeiro dia vira um inquérito público, não apenas uma tarde lenta.
Vocês já derrubaram deliberadamente um componente em produção, e o nível de redundância de cada sistema de fato corresponde à sua criticidade e ao seu custo? A resiliência que nunca foi testada é uma hipótese, e os níveis que vocês podem comprar vão da barata cópia e restauração à espera morna e ao caro multirregional ativo-ativo, então a disciplina é gastar garantia onde ela se justifica em vez de dourar tudo ou não proteger nada. As considerações concorrentes são raio de impacto e orçamento: os experimentos de caos precisam de proteções e de uma chave de abortar, e o ativo-ativo para uma ferramenta interna de relatórios é desperdício enquanto cópia apenas para uma plataforma de pagamentos é negligência. Levem um inventário dos seus pontos únicos de falha, o nível de redundância de cada sistema crítico e a evidência da última injeção controlada de falha e do que ela revelou. Em portfólios corporativos e governamentais, mapeiem cada nível a uma classificação documentada de criticidade para que um auditor veja que o dinheiro segue o risco e ninguém precise defender o gasto pela primeira vez durante a queda.

Perspectiva por setor

Startup. Você não consegue prever se um lançamento traz cinquenta cadastros ou cinquenta mil, então compre escala em vez de construí-la: rode serviços sem estado atrás de um balanceador de carga gerenciado e deixe a plataforma escalar automaticamente pela taxa de requisições. Defina um orçamento modesto de desempenho e escolha armazenamentos de dados gerenciados para que um pico não force uma rearquitetura às 2 da manhã. Pule por ora a recuperação de desastres multirregional e os programas de caos. Mantenha cópias testadas e gaste a sua escassa atenção de engenharia no produto, não numa redundância que o seu tráfego ainda não justifica.

Pequena empresa. Sem especialista em confiabilidade e com orçamento apertado, a escolha entre comprar e construir pende com firmeza para comprar: uma plataforma gerenciada ou uma pilha serverless faz do escalamento e do failover tarefa do provedor, e uma única região bem operada costuma bastar. Enquadre a resiliência como um pequeno número de promessas concretas que você consegue cumprir, como uma cópia noturna da qual você de fato restaurou uma vez e uma janela realista de recuperação que você comunicou aos clientes. Evite pagar por ativo-ativo ou por teste contínuo de carga que você não tem tráfego nem equipe para justificar.

Grande empresa. O problema é a consistência entre muitas equipes: padronize orçamentos de desempenho impostos na CI, uma biblioteca compartilhada de padrões de resiliência (tempos limite, disjuntores, anteparas) e um nível documentado de redundância para cada sistema ligado à sua criticidade. Reserve o multirregional ativo-ativo para os serviços de nível um, conduza um programa de engenharia do caos com proteções e dias de simulação em produção e trate o planejamento de capacidade para picos conhecidos como uma disciplina agendada e não uma reflexão tardia. Governe o RTO e o RPO centralmente para que todo sistema crítico tenha objetivos com responsável e testados que um auditor possa verificar.

Governo. A carga muitas vezes é cronometrada por lei e as obrigações de disponibilidade são estatutárias, então o planejamento de capacidade não pode depender de o escalamento automático reagir na hora: preveja o pico do prazo, pré-provisione e teste a carga bem acima da previsão. A contratação deve especificar o RTO, o RPO e um cronograma de failovers ensaiados como exigências contratuais, não promessas de fornecedor, e deve evitar o aprisionamento a uma única região para serviços críticos. Decidam de antemão qual caminho é legalmente essencial (enviar uma declaração, pedir um benefício) para que a degradação descarte primeiro os painéis de status e as consultas, e sejam transparentes com o público sobre quedas e recuperação em vez de esperar que ninguém note.

Exemplos

Startup. Uma pequena startup que lança no Product Hunt não consegue prever se terá cinquenta cadastros ou cinquenta mil, então mantém seus serviços sem estado atrás de um balanceador de carga gerenciado e deixa a plataforma escalar automaticamente pela taxa de requisições. Define um orçamento modesto de desempenho (as páginas respondem em menos de 300 ms no percentil 95) e escolhe um banco de dados gerenciado para que um pico de tráfego não force uma rearquitetura às 2 da manhã. Quando o pico do dia do lançamento de fato chega, o site fica um pouco mais lento em vez de cair, e a equipe passa o dia conversando com os novos usuários em vez de lutar contra uma queda.

Grande empresa. Uma empresa de mídia em streaming opera serviços sem estado em várias regiões atrás de balanceamento de carga global, escalando automaticamente pela taxa de requisições para acompanhar a onda diária do horário nobre. Os orçamentos de desempenho servem de portão para todo lançamento sobre a latência p99 de início. Sob uma falha regional, o tráfego se desloca automaticamente para regiões saudáveis, e as funcionalidades não essenciais (capas personalizadas, atualização de recomendações) se degradam primeiro para proteger a reprodução. A empresa conduz experimentos contínuos de caos em produção, rotineiramente encerrando instâncias e injetando latência, de modo que falhas reais sejam indistinguíveis de simulações e não causem nenhuma queda visível ao cliente.

Governo. Uma autoridade tributária sabe que seu sistema de declaração enfrenta todo ano um pico enorme e legalmente fixo no prazo. Em vez de contar com o escalamento automático para reagir na hora, ela prevê a carga de pico a partir dos anos anteriores, pré-provisiona capacidade com semanas de antecedência e testa a carga até 150% da previsão. A arquitetura é sem estado atrás de balanceadores de carga com uma segunda região em espera morna. O RTO e o RPO são definidos por política (no máximo 15 minutos de indisponibilidade e perda de dados próxima de zero para as declarações enviadas), e o failover é ensaiado trimestralmente. Sob carga extrema, as funcionalidades não críticas (painéis de status, consultas históricas) são descartadas primeiro para que o envio da declaração, o caminho legalmente essencial, continue disponível.

Justificativa de negócio: motivações, ROI e TCO

A escalabilidade, o desempenho e a resiliência são casos clássicos em que o custo da falha supera de longe o custo da prevenção. Mas a prevenção é visível no orçamento e a falha é só potencial, e é por isso que são cronicamente subfinanciadas até o primeiro desastre. O custo de adoção é real: infraestrutura redundante, capacidade multirregional, ferramentas de teste de carga e de caos e o tempo de engenharia para construir a ausência de estado e os padrões de resiliência. O custo de não investir é uma queda de grande visibilidade durante a demanda de pico: receita perdida por minuto no comércio, obrigações estatutárias perdidas e inquérito público no governo, penalidades de acordo de nível de serviço (SLA) e dano duradouro à reputação.

Enquadre o caso junto à liderança com números que o negócio já entende. Estime o custo de uma hora de indisponibilidade no pico (transações perdidas, penalidades, remediação, reputação) e compare-o com o custo anual da redundância e dos testes que a previnem. Para sistemas críticos a prevenção é quase sempre uma fração de um único grande incidente. Ligue o RTO e o RPO a dinheiro explícito: quanta receita ou quantas transações por hora de indisponibilidade e quanta perda de dados é legal ou comercialmente tolerável. Apresente o desempenho como alavanca de receita e de satisfação, já que sistemas mais rápidos convertem melhor e custam menos por transação, e apresente a resiliência como um seguro cujo prêmio é pequeno diante da perda coberta. O argumento mais forte é que essas qualidades são baratas de projetar e ruinosas de adaptar depois da queda que força a questão.

Antipadrões e armadilhas

Sessões fixas e estado na instância. Guardar o estado de sessão no servidor, impedindo o escalamento horizontal livre e a substituição segura de instâncias.
Escalamento automático como planejamento de capacidade. Presumir que o escalamento automático absorverá um pico em degrau conhecido a que é lento demais para reagir.
Operar a quente sem folga. Operar perto de 100% de utilização, sem deixar nada para absorver picos ou falhas.
Otimizar sem fazer profiling. Ajustar código que não é o gargalo enquanto o gargalo real fica intocado.
Ignorar a cauda. Relatar a latência média enquanto os usuários do p99 sofrem. As médias escondem a dor em escala.
Recuperação de desastres não testada. Um plano de recuperação e cópias que nunca foram exercitados e que falharão quando necessários.
Pontos únicos de falha. Um balanceador de carga, um primário de banco de dados, uma região: um componente sem redundância que derruba tudo.
Engenharia do caos sem proteções. Injetar falhas sem controle de raio de impacto nem chave de abortar, causando a própria queda que se pretendia prevenir.

Modelo de maturidade

Nível 1: Iniciar. Ad hoc e reativo. Instância única ou escalada verticalmente, com estado guardado no servidor. Sem teste de carga, sem orçamentos de desempenho e sem recuperação de desastres além de cópias ocasionais das quais ninguém restaurou. Qualquer falha de componente causa uma queda total, e os problemas de escala são descobertos em produção.
Nível 2: Desenvolver. Aparecem práticas básicas mas que variam de equipe para equipe. Alguns serviços são escalados horizontalmente e sem estado atrás de um balanceador de carga, com escalamento automático básico em alguns deles. O teste de carga acontece antes de grandes lançamentos mas não rotineiramente, e existem cópias enquanto a recuperação de desastres é documentada mas raramente exercitada. O que uma equipe faz bem outra ainda não começou.
Nível 3: Padronizar. As práticas são documentadas e impostas em toda a organização. A capacidade é planejada para picos conhecidos com folga, os orçamentos de desempenho são impostos na CI de modo que as regressões quebram o build e os padrões de resiliência (tempos limite, novas tentativas limitadas, disjuntores, anteparas) mais a degradação graciosa são o padrão. O RTO e o RPO são definidos por sistema, os níveis de redundância são atribuídos pela criticidade e o failover da recuperação de desastres é testado numa agenda regular em todas as equipes.
Nível 4: Gerenciar. As qualidades são medidas e controladas em relação a linhas de base. As equipes acompanham a latência p95 e p99, os orçamentos de erro e a utilização e a folga contra a previsão e alertam sobre violações em vez de descobri-las no lançamento. Os tempos testados de failover são comparados ao RTO e ao RPO-alvo, os limites de degradação e de descarte de carga são validados com métricas e as decisões de seguir ou não com lançamentos e capacidade são conduzidas por dados. Onde os números derivam da linha de base, a lacuna é visível e tem responsável em vez de escondida atrás de médias.
Nível 5: Orquestrar. A escalabilidade, o desempenho e a resiliência são continuamente melhorados e integrados em toda a organização. O multirregional ativo-ativo é usado onde a criticidade o justifica, a engenharia do caos roda continuamente, incluindo dias de simulação em produção, e a previsão de capacidade alimenta diretamente o planejamento e as compras. A resiliência é validada de modo contínuo, os objetivos de recuperação são consistentemente atingidos e provados, e a arquitetura se adapta conforme os padrões de carga e o quadro de riscos mudam, ligada à continuidade de negócio e ao planejamento de riscos.

Ideias para discussão

Quais dos seus serviços ainda guardam estado na instância, e o que impede vocês de torná-los sem estado?
Para o seu sistema mais crítico, quais são o RTO e o RPO, quem os definiu e quando foi a última vez que vocês provaram que conseguem cumpri-los?
O escalamento automático de fato protege vocês contra o seu maior pico conhecido, ou vocês dependem dele para fazer algo que ele não consegue?
Onde está o seu ponto único de falha remanescente, e qual é o plano para removê-lo?
Vocês estão medindo e orçando a latência p99, ou se escondem atrás de médias?
Vocês já falharam deliberadamente um componente em produção? Se não, como sabem que a sua resiliência funciona?

Principais conclusões

Distinga desempenho, escalabilidade e resiliência. Um grande sistema precisa das três, projetadas desde o início.
O escalamento horizontal e os serviços sem estado são a fundação da escala, da disponibilidade e da implantação segura.
Combine o escalamento automático com planejamento real de capacidade e folga para os picos previsíveis e críticos para o negócio.
Conduza o desempenho com profiling e teste de carga contra orçamentos explícitos, concentrando-se no caminho crítico e na cauda.
Construa a resiliência com tempos limite, disjuntores, anteparas, degradação graciosa e redundância e depois valide-a com a engenharia do caos.
Defina o RTO e o RPO como decisões de negócio, projete a recuperação de desastres para corresponder à criticidade de cada sistema e teste o failover regularmente.

Referências e leitura complementar

Martin Kleppmann, Designing Data-Intensive Applications
Michael Nygard, Release It!: Design and Deploy Production-Ready Software
Betsy Beyer et al. (Google), Site Reliability Engineering and The Site Reliability Workbook
Casey Rosenthal and Nora Jones, Chaos Engineering
Brendan Gregg, Systems Performance: Enterprise and the Cloud
John Allspaw, The Art of Capacity Planning
Ilya Grigorik, High Performance Browser Networking
Nassim Nicholas Taleb, Antifragile