Escalabilidade e confiabilidade

Nível: B2

Objetivo

Discutir crescimento de sistemas em inglês usando o vocabulário de escalabilidade e confiabilidade (availability, reliability, redundancy, failover, throughput, load, capacity planning), explicando trade-offs entre custo, complexidade e risco, e descrevendo decisões de arquitetura com clareza em post-mortems, design reviews e capacity reviews.

Explicação

Em discussões de engenharia maduras, escalabilidade e confiabilidade deixam de ser palavras isoladas e passam a descrever um sistema de decisões: quanto tráfego o sistema aguenta, o que acontece quando uma peça falha, quanto tempo de parada o negócio tolera, e quanto custa chegar lá. Em B2, espera-se que o engenheiro descreva essas decisões em frases completas, comparando alternativas e justificando escolhas.

1. Os eixos do vocabulário

• Availability (disponibilidade) é a fração do tempo em que o sistema responde. Costuma-se medir em "nines": 99.9% (three nines) é o mínimo aceitável para muitos serviços internos; 99.99% (four nines) já exige redundância e failover ativos.
• *The service is aiming for 99.95% availability this quarter.*
• *Lower availability means more downtime, which means more support tickets.*

• Reliability (confiabilidade) é a probabilidade de o sistema funcionar corretamente durante um intervalo. Não é a mesma coisa que availability: um sistema pode estar disponível, mas retornando respostas erradas (baixa confiabilidade).
• *We measure reliability with the error budget, not just with uptime.*
• *Higher reliability usually costs more in hardware and in engineering time.*

• Redundancy (redundância) é ter componentes a mais do que o mínimo necessário para que, se um falhar, outro assuma. Pode ser ativo-ativo (ambos servem tráfego) ou ativo-passivo (o secundário só entra em ação em failover).
• *The database has redundancy across three availability zones.*
• *Redundancy increases cost, but it cuts the blast radius of a single failure.*

• Failover é a troca automática para um componente redundante quando o primário falha. O failover pode levar segundos ou minutos; durante esse intervalo, a disponibilidade cai.
• *Failover took 40 seconds, which is too long for a user-facing service.*
• *We tested the failover last week, and it worked, but the cold cache hurt latency.*

• Throughput é a quantidade de trabalho que o sistema processa por unidade de tempo (requests per second, MB per second, mensagens por minuto). Throughput alto com latência alta geralmente é sinal de fila crescendo.
• *Peak throughput last Friday was 12k requests per second.*
• *The database is the bottleneck; the API tier could handle three times that throughput.*

• Load (carga) é a demanda atual sobre o sistema. Load testing simula carga sintética para ver como o sistema se comporta antes de um evento real (Black Friday, lançamento, jogo).
• *The service fell over at 80% of the expected load.*
• *We need to see how the new region behaves under load.*

• Capacity planning (planejamento de capacidade) é a previsão de quanto recurso será necessário (CPU, memória, banda, conexões de banco) dado o crescimento esperado, e a decisão de quando provisionar.
• *Capacity planning is part art, part spreadsheet: estimate growth, add headroom, and revisit every quarter.*
• *If we wait for the system to saturate, we will be reactive, not proactive.*

2. Formas de escalar

• Scale up / scale vertically: aumentar o recurso da máquina (mais CPU, mais RAM).
• Scale out / scale horizontally: adicionar mais instâncias do mesmo serviço.
• Scale down / scale in: remover instâncias em horário de baixo tráfego para economizar.

Em geral, scale out dá mais disponibilidade (uma instância pode falhar e as outras continuam), mas exige que o sistema seja stateless ou que o estado seja compartilhado. Scale up é mais simples, mas cria um single point of failure maior.

3. Frases típicas em capacity review

Em uma capacity review, espera-se que o engenheiro:

1. Cite números: *We're at 60% of CPU and 70% of DB connections at peak.*
2. Projete crescimento: *At the current rate, we will saturate the database in roughly two months.*
3. Compare alternativas: *We can either scale up the primary, which is fast but expensive, or shard the writes, which is cheaper long-term but risky.*
4. Recomende com trade-off explícito: *I recommend we shard the writes, even though it adds complexity, because the cost difference is significant and the risk is manageable with feature flags and a canary.*
5. Defina gatilhos: *If we hit 80% of DB connections, we trigger a scale-up; if we hit 90%, we trigger a paging alert.*

Esse padrão (situação → projeção → alternativa → recomendação → gatilho) é o esqueleto de quase toda conversa séria sobre escalabilidade e confiabilidade em inglês.

4. Reliability vs. cost: o trade-off central

Quase toda decisão de confiabilidade é também uma decisão de custo: mais redundância significa mais instâncias, mais banco, mais rede. Quase toda decisão de custo é também uma decisão de risco: cortar redundância economiza agora, mas aumenta a chance de um incidente custoso depois. O trabalho do engenheiro B2 é tornar esse trade-off explícito em vez de implícito.

• *We are paying for redundancy we don't need during business hours, but we do need it at peak.*
• *The cheaper region is fine for now, but the failover time is unacceptable for a payments service.*
• *I would rather over-provision this quarter than miss our SLO.*

Exemplos

Erros comuns

• Confundir availability e reliability: um sistema pode estar disponível (up) e pouco confiável (respondendo errado); em capacity review, sempre nomeie os dois separadamente.
• Dizer "the system is scalable" sem qualificar: escalabilidade é para que dimensão (read traffic, write traffic, storage, concurrent users) e até que ponto; seja específico.
• Traduzir "throughput" como "largura de banda": throughput é trabalho concluído (requests per second, mensagens processadas), não a capacidade do link de rede.
• Usar failover como verbo solto: prefira *trigger a failover*, *test the failover*, *failover took 40 seconds*; "to failover" como verbo simples é aceito, mas mais raro em texto formal.
• Confundir scale up (vertical) com scale out (horizontal): scale up aumenta a máquina; scale out adiciona máquinas. Misturar os dois em uma frase gera ambiguidade na review.
• Esquecer o trade-off: dizer *we should add redundancy* sem mencionar o custo torna a frase fraca em B2; sempre acompanhe com a consequência (*which adds $X/month, but cuts downtime by Y*).
• Subir gatilhos vagos: *we will scale when needed* não é operável. Em capacity review, defina números (CPU %, DB connections, queue depth) e ações (scale-up, page on-call, freeze deploys).

Prática guiada

Reescreva cada bloco seguindo o padrão *situação → projeção → alternativa → recomendação → gatilho*.

1. Situação + projeção

`The payments service is at 65% of its DB connection pool. Traffic is growing 10% per month.` → `At the current rate, the payments service will saturate the database in roughly three months.`

1. Alternativas

`We can add a read replica, or we can increase the pool size on the primary.` → `We can either add a read replica, which is cheaper but only helps reads, or increase the pool size, which is fast but doesn't address the long-term growth.`

1. Recomendação com trade-off

`I think we should add the replica.` → `I recommend we add the read replica, even though it adds a small replication lag, because the cost is lower and the long-term write growth still gives us headroom.`

1. Gatilho concreto

`We will act when things get bad.` → `If DB connections hit 80%, we open a ticket to raise the pool; if they hit 90%, we page the on-call.`

Repare que cada frase carrega um número, um verbo de ação e uma consequência — é isso que transforma opinião em recomendação.

Resumo

Escalabilidade e confiabilidade são descritas em inglês com vocabulário preciso: availability (fração de tempo up), reliability (probabilidade de funcionar corretamente), redundancy (componentes a mais), failover (troca para o redundante), throughput (trabalho por unidade de tempo), load (demanda atual) e capacity planning (previsão de recurso). Formas de escalar: scale up (vertical, mais recurso na máquina) e scale out (horizontal, mais instâncias). Em capacity review B2, use o padrão situação → projeção → alternativas → recomendação com trade-off → gatilhos numéricos, e sempre mencione custo e risco juntos em vez de tratá-los separadamente.

História: Escalabilidade e confiabilidade

Nível: B2

História em inglês

The capacity review

On Monday morning, Daniel opened the capacity review deck for the upcoming Black Friday. The platform, which had grown 40% over the last year, was now serving more than 8 million daily active users. Peak throughput last Black Friday had been 12k requests per second, and the team expected at least 18k this year. Daniel, who had led the previous two reviews, knew the numbers were tight, but the budget was tighter. What worried him most was that the payments service was still a single point of failure for the whole checkout flow.

Reading the metrics

He started with the dashboard, which showed the system at 70% of the database connection pool at last week's peak. The API tier, by contrast, was only at 35% of CPU, which meant it could scale out easily if needed. At the current growth rate, the team would saturate the database in roughly ten weeks, which was three weeks before Black Friday. Reliability had been slipping for two months, mostly because the cache layer was returning stale data during deploys. Availability was still high, around 99.94%, but the error budget was nearly gone.

Weighing the options

Daniel then wrote the options page, which is the part leadership actually reads. The first option was to scale up the primary database, which would be fast and low risk, but expensive in the long run. The second option was to shard the writes, which would be cheaper and more sustainable, but it would add complexity and take three months. The third option was to add a read replica and rely on it for most of the catalog traffic, which would cut the read load on the primary by almost half. Considering the trade-off between cost, complexity, and time, Daniel marked the third option as his recommendation, but he asked the team to challenge it.

The discussion in the room

In the meeting, Priya pushed back: "The replica helps reads, but the bottleneck is the write path, not the read path." Daniel agreed that the write path was the real risk, but he argued that over-provisioning the primary for one quarter was the safer move while the team built the sharding plan. "I would rather over-provision this quarter than miss our SLO," he said, and Priya nodded. They agreed to combine both: add the read replica, scale up the primary by 30%, and start the sharding project in parallel with a hard deadline. The question was whether the security review for the replica would land in time, but Daniel said that was a known dependency and not a blocker.

Closing the review

At the end of the meeting, Daniel added the action items, which were the only thing the engineering managers would actually check. Action one: provision two read replicas in the new region by the end of the month. Action two: scale up the primary database to 1.5x its current size, with a 20% headroom target. Action three: if DB connections hit 80%, page the on-call; if they hit 90%, open an incident and freeze deploys. Approved by the EM, the review went into the shared drive, and the team left the room knowing exactly what would happen, when, and why.

Tradução linha por linha

Notas de vocabulário

• the platform, which had grown 40% over the last year = non-defining relative clause com which + past perfect: a informação extra sobre a plataforma
• Daniel, who had led the previous two reviews = non-defining relative clause com who: dado extra sobre uma pessoa já identificada
• Peak throughput last Black Friday had been 12k requests per second = throughput + número + unidade (requests per second): padrão para descrever capacidade
• single point of failure = componente sem redundância cuja falha derruba o sistema inteiro
• the system at 70% of the database connection pool = percentual do pool é o indicador padrão de saturação de banco
• the API tier, by contrast, was only at 35% of CPU = by contrast = em contraste: separa o lado saudável do gargalo
• At the current growth rate, the team would saturate the database in roughly ten weeks = at the current rate + would + verbo + in + duration: padrão para projetar saturação
• the cache layer was returning stale data = exemplo clássico de sistema disponível (up) mas pouco confiável (reliability baixa)
• the error budget was nearly gone = error budget = margem de erro permitida; "burn the error budget" = consumir essa margem
• scale up the primary database = scale up = mais recurso na mesma máquina; em contraste com scale out (mais máquinas)
• shard the writes = shard = fragmentar dados em partições; comum em cenários de alto write throughput
• add a read replica = read replica = cópia do banco usada só para leituras, alivia o primário
• Considering the trade-off between cost, complexity, and time = present participle clause inicial; trade-off between A, B, and C é o padrão para listar eixos
• I would rather over-provision this quarter than miss our SLO = I would rather + base verb + than + base verb: preferência explícita entre duas ações
• if DB connections hit 80%, page the on-call = if + metric + hit + threshold + imperative: padrão para gatilho numérico e ação concreta

Perguntas de compreensão

1. What was Daniel preparing on Monday morning?
2. What was last year's peak throughput, and what does the team expect this year?
3. What was the main reliability risk Daniel worried about?
4. What was the system at last week's peak, in terms of the database connection pool?
5. Why was reliability slipping for two months?
6. What were the three options Daniel presented?
7. Which option did Daniel recommend, and why?
8. What did Priya push back on?
9. What did the team agree to do in the end?
10. What are the three action items that came out of the review?

Prática com a história

1. Reescreva com non-defining relative clause: The platform grew 40% last year. The platform serves 8 million DAU.
2. Reescreva usando Present participle clause inicial: The team considered the trade-off. Daniel recommended the read replica.
3. Reescreva com noun clause depois de agreed: They agreed. They would combine both approaches.
4. Reescreva com I would rather: I prefer over-provisioning. The other option is missing our SLO.
5. Reescreva com if + hit + threshold + imperative: 80% means page the on-call. 90% means open an incident.