Cache e escalabilidade de bancos de dados

A camada de dados é onde a escala fica cara. Adicionar instâncias de aplicação é barato e reversível; adicionar capacidade de banco custa dinheiro, tempo e às vezes uma janela de indisponibilidade. Este tópico cobre as duas saídas: parar de fazer o trabalho repetido, colocando um cache no lugar certo, e escalar o banco quando o trabalho que sobra é real. Ele fecha as Skills 2.1.2 e 2.1.3 do SOA-C03, e quase toda questão dessas skills é um diagnóstico, não uma definição.

O que este tópico cobre

• A escolha entre CloudFront e ElastiCache, e o que decide qual dos dois tira carga de verdade num cenário
• A cache key e os TTLs do CloudFront: como origem e cache policy negociam a duração, por que um Minimum TTL maior que 0 sobrepõe no-store, e como subir a taxa de cache hit encolhendo a key
• Invalidation contra nomes de arquivo versionados, com a franquia de 1.000 caminhos por mês e as armadilhas de wildcard e query string
• Lazy loading, write-through e TTL no ElastiCache, a falha que cada estratégia carrega, e as diferenças de engine entre Memcached, Valkey e Redis OSS que decidem quais ações de escala existem
• Standby Multi-AZ, read replica do RDS e Aurora Replica: método de replicação, quem serve leitura e para que cada um existe
• Storage autoscaling do RDS com suas três condições de gatilho, RDS Proxy para esgotamento de conexões, e o cluster volume compartilhado que dá ao Aurora reader endpoints, Auto Scaling de readers e capacidade Serverless em ACUs
• RCUs e WCUs com as regras de arredondamento e consistência, on-demand contra provisionado com auto scaling, e por que uma tabela sofre throttle com capacidade sobrando
• Burst capacity, adaptive capacity e o teto rígido por partição, mais o que o DAX guarda, o que ele repassa e quando ele devolve dado velho

Por que isso importa

Os enunciados desta parte da prova quase sempre trazem um sintoma e pedem a causa: conteúdo personalizado servido para o visitante errado, um cluster de cache com latência subindo e a CPU aparentemente baixa, relatórios apontados para uma instância que não aceita leitura, uma política de Aurora Auto Scaling que não dispara com dois readers no talo, uma tabela do DynamoDB com throttle e 100 WCUs sobrando. Cada um desses tem uma causa exata e um conserto exato, e nenhum deles aparece se você só decorou o que cada serviço faz.

Em produção a diferença é ainda mais direta. Saber que o dado no cache tem um teto de idade e não uma garantia de frescor muda o que você promete numa revisão de arquitetura. Saber que replica lag existe muda onde você manda uma leitura logo após uma escrita. E saber que vazão do DynamoDB é aplicada por partição é a diferença entre consertar uma partition key e provisionar capacidade que nunca vai chegar na requisição que precisava dela.