Matheus Fidelis - Engineering Blog

System Design - Observabilidade e Monitoramento

Thu, 19 Mar 2026 00:00:00 +0000

Após elaborarmos diversos tópicos como Performance, Capacidade e Escalabilidade, Métricas de Continuidade de Negócio e diversos outros assuntos relacionados, este capítulo tem o objetivo de fazer um “recap” de alguns conceitos de forma simplificada, trazendo o ponto de vista final de Observabilidade, Monitoramento e Confiabilidade. Nele, vamos conceituar algumas pontas soltas referentes a Logs, Métricas, Traces, Alerting e APM, e principalmente como utilizar a simplicidade de diversos frameworks de mercado, como USE, RED e os Four Golden Signals, alinhados ao negócio para encontrar métricas comuns, de fácil entendimento e, principalmente, alinhadas entre times técnicos e de negócio.

Aqui, vamos elucidar principalmente como os temas de Observabilidade, Monitoramento e Confiabilidade se correlacionam e se complementam entre si. Vamos entender cada um dos pilares da observabilidade e qual tipo de entendimento estratégico precisamos ter sobre cada um deles.

Definindo Confiabilidade

Confiabilidade é a propriedade de um sistema entregar comportamento correto ao longo do tempo, sob condições esperadas e sob uma fração representativa de condições adversas. Confiabilidade vai muito além de uma aplicação “ficar de pé” e não é sinônimo direto de “alta disponibilidade”. Um sistema pode estar tecnicamente disponível e, ainda assim, ser pouco confiável se responde com dados errados, se degrada de forma caótica, se apresenta latência imprevisível ou se não consegue manter invariantes essenciais do domínio quando pressionado.

Confiabilidade, portanto, agrega os conceitos de continuidade de serviço, integridade e previsibilidade em termos operacionais.

A utilidade dessa definição é que ela coloca confiabilidade no lugar certo: como uma restrição arquitetural e um contrato operacional, e não como um “atributo desejável”. A partir daqui, todos os termos que serão abordados neste capítulo, como SLIs/SLOs, error budget, Four Golden Signals, RED e USE, e demais estratégias abordadas em outros capítulos, como estratégias de redundância, padrões de resiliência e práticas de incident response, passam a ser consequência de um objetivo: reduzir a probabilidade e o impacto de comportamentos incorretos, reduzir o tempo para detectar e recuperar e limitar o blast radius quando algo inevitavelmente falhar.

A confiabilidade, então, é um conjunto de práticas e disciplinas da engenharia e arquitetura de software que busca atingir níveis cada vez maiores e auditáveis de continuidade operacional.

Observabilidade

Observabilidade é a capacidade de inferir o estado interno de um sistema a partir de suas saídas externas. O termo tem origem na Teoria de Controle, da década de 1960, introduzida academicamente por Rudolf E. Kalman, por meio de publicações sobre a teoria de sistemas lineares.

A Teoria do Controle é um ramo da engenharia e da matemática que estuda como modelar, analisar e regular o comportamento de sistemas dinâmicos para projetar sistemas complexos que se comportem de maneira estável ao longo do tempo, mesmo diante de perturbações externas ocasionais. Na teoria, um sistema é dito observável caso exista a capacidade de inferir o estado interno de um sistema apenas por suas saídas externas.

A observabilidade em sistemas de software depende de saídas, registros e métricas de desempenho para cumprir esse papel. Trata-se da capacidade de compreender o estado interno de um sistema complexo a partir dos eventos e sinais externos que ele emite.

Esses eventos e sinais podem ser traduzidos, inicialmente, nos três pilares da observabilidade: logs, traces e métricas. O objetivo é entender comportamento, padrões e construir estruturas que sejam “interrogáveis” por meio de padrões e dimensões conhecidas e não conhecidas. Podemos presumir que: uma vez que conseguimos correlacionar logs, traces e métricas para elaborar questionamentos complexos sobre o sistema, temos observabilidade. E, ainda mais, se podemos utilizar logs, traces e métricas para conduzir análises exploratórias, temos observabilidade.

Por mais que seja altamente dependente, a observabilidade é uma propriedade estrutural de um sistema, e não um conjunto de ferramentas. É altamente possível que empresas, produtos e estruturas inteiras disponham de ferramentas altamente complexas e caras e, mesmo assim, não possuam observabilidade em essência.

À medida que nosso ferramental é utilizado para interpretar comportamentos, e podemos utilizá-lo, técnica e culturalmente, para entender comportamentos e padrões ocultos de forma histórica, temos observabilidade.

Monitoramento e Observabilidade

O monitoramento e a observabilidade são conceitos que caminham juntos, de forma tão tênue que normalmente são confundidos e referenciados como se fossem a mesma coisa. Entender a diferença entre os dois pode ser de grande ajuda para elevar o nível de confiabilidade nos sistemas. Os dois conceitos não são excludentes, mas complementares em essência.

Monitoramento é a capacidade de coleta e análise de métricas pré-definidas, de contextos já vividos, para verificar o estado de um sistema a partir de dimensões já conhecidas. O monitoramento nos dá a capacidade de monitorar, verificar e alertar quando algo conhecido dá errado, como, por exemplo, aumento de erros em APIs específicas, saturação de recursos, locks em um banco de dados, aumentos no tempo de resposta, etc.

O monitoramento se desenvolve normalmente por meio de medidas quantitativas, como, por exemplo, porcentagem de uso de CPU, latência de rede, quantidade de dados de entrada e saída de rede, taxas de erro, espaço em disco, etc., e, com base nisso, permite configurar thresholds para disparar alertas quando algo sai de um padrão estabelecido.

Observabilidade, por outro lado, é a capacidade de investigar fenômenos desconhecidos por meio da exploração de dados contextuais mais amplos e entender o “porquê” de algo inesperado ter acontecido. Deixamos de observar um estado determinístico, como “minha API está lenta”, e expandimos isso para “por que essa API está lenta agora?”, analisando todos os sinais de forma correlacionada para compreender o comportamento.

Resumindo, o monitoramento está diretamente ligado a identificar e alertar sobre problemas conhecidos, enquanto a observabilidade está ligada ao comportamento. Uma vez que sua observabilidade possibilita encontrar padrões e investigar problemas não óbvios, essas novas dimensões descobertas podem ser utilizadas como insumos para gerar monitoramento. Observabilidade está correlacionada a comportamento e exploração; monitoramento é acompanhamento.

Monitoramento como Detecção de Sintomas

Monitoramento é, em essência, a disciplina de detectar sintomas conhecidos de degradação, falha ou risco operacional. Antes de qualquer coisa, só monitoramos o que é claro e conhecido. Ter clareza sobre esse conceito é muito importante para a sua diferenciação. Ele parte do princípio de que já sabemos, com algum grau de clareza, quais sinais merecem ser acompanhados e quais desvios desses sinais representam uma ameaça à saúde do sistema. O monitoramento trabalha com métricas, eventos e thresholds previamente definidos, observando comportamentos esperados e disparando alertas quando algo sai da normalidade conhecida.

Quando configuramos alertas para dimensões conhecidas, como aumento de taxa de erro, aumento de latência, saturação de CPU e memória, filas ou tópicos acumulando mensagens e eventos, locks em banco de dados ou falhas em health checks, estamos modelando sintomas de que algo pode estar errado. Não estamos necessariamente explicando a causa do problema, mas detectando que algo não está de acordo.

O monitoramento pode ter sinais padronizados dentro de uma organização, mas é de extrema importância entender que ele é evolutivo e amadurece junto ao sistema e ao time de engenharia. Sintomas conhecidos dependem de conhecimento prévio. Monitoramos aquilo que já aprendemos a medir, aquilo que já sabemos que pode falhar ou aquilo que já identificamos historicamente como importante, e revisitamos esses critérios sempre que algo estrutural muda.

Observabilidade como Comportamento

Como vimos, o monitoramento está orientado a sintomas conhecidos. A observabilidade, por sua vez, está orientada a comportamento. Ela é a capacidade de explorar os sinais emitidos por um sistema de forma correlacionada para compreender como ele está se comportando internamente, mesmo quando o problema ainda não foi previamente modelado como uma condição de alerta. Enquanto o monitoramento pergunta “algo conhecido saiu do normal?”, a observabilidade permite perguntar “o que está acontecendo dentro do sistema para que esse comportamento esteja acontecendo agora?”.

Em sistemas distribuídos, uma degradação pode nascer em um ponto e se manifestar em outro. Uma causa pequena pode produzir um efeito grande, dependendo da carga, da topologia e das dependências envolvidas. A observabilidade nos ajuda a correlacionar logs, métricas e traces emitidos por vários serviços envolvidos em uma transação para encontrar a origem de um comportamento com desvio.

Por isso, dizer que observabilidade está ligada a comportamento é dizer que ela se interessa menos por valores isolados e mais pela forma como o sistema reage ao longo do tempo, sob diferentes condições.

Três Pilares da Observabilidade

A observabilidade é a correlação direta de três pilares principais, sendo eles Métricas, Logs e Traces. Todos possuem valor individual e seu contexto sistêmico; porém, quando somados e correlacionados, podemos expandir esses sinais isolados para uma visão de comportamento mais ampla de ambientes complexos. Nesta seção, temos o objetivo de abordar cada um dos três pilares e explorar seus agregados, como Alerting e APM.

Métricas

Métricas são aspectos quantitativos e estatísticos do software que têm o objetivo de medir comportamentos, desempenho e demais estados de um sistema ao longo do tempo. Métricas, por si só, possuem características temporais e fornecem uma visão de tendências ao longo de períodos do dia. Métricas podem operar tanto no nível técnico quanto no de negócio. Existem métricas técnicas, como tempo de resposta, quantidade de sucessos, quantidade de erros, contadores de status codes, métricas de estado de circuit breakers (abertos e fechados), acionamentos de fallbacks, etc. As métricas de negócio operam em um nível mais característico e específico da aplicação e podem ser variações como quantidade de vendas, quantidade de pagamentos aceitos, pagamentos recusados, quantidade de transações autorizadas ou negadas, quantidade de recusas por falta de saldo e demais validações.

Contadores

Contadores são valores que apenas aumentam (ou resetam para zero, como na reinicialização de um serviço). É útil contar o número de eventos, como requisições totais, erros, itens processados com sucesso, itens processados com erro, circuitos abertos, etc. Durante a coleta, esses valores podem ser agregados em séries temporais para entender comportamentos de utilização e picos.

Gauges

Um gauge representa um valor numérico que pode aumentar ou diminuir. É ideal para medir valores pontuais, como uso de CPU, memória em uso, número de conexões ativas, tempos de resposta, etc. Ao contrário dos contadores, os gauges representam registros de valores absolutos que podem variar ao longo do tempo.

Histogramas

Os histogramas agregam observações (como durações de requisições ou tamanhos de resposta) e as agrupam em baldes (buckets) configuráveis. Eles permitem calcular quantis e percentis (ex.: “99% de todas as requisições foram concluídas em menos de 300 ms”), etc. Eles nos ajudam a explorar agregações de métricas de forma mais complexa e aprofundada, analisando a dispersão dos dados por meio de várias dimensões, como média, mediana, percentis e desvio padrão.

Traces

Em ambientes distribuídos de microserviços, uma única transação pode passar por dezenas de serviços diferentes para ser considerada concluída. Traces têm o objetivo de capturar amostras de solicitações, detalhando-as de ponta a ponta, catalogando todas as entradas e saídas de uma transação por meio de múltiplos componentes de um sistema distribuído.

Eles mostram o caminho de ponta a ponta da transação, incluindo tempos de processamento, latência, erros de chamada entre serviços, etc. Diferentemente dos logs, que são isolados, os traces conectam eventos em uma narrativa coesa, revelando como diferentes partes do sistema interagem.

Traces são utilizados para entender erros e desvios de tempos de resposta de uma transação e facilitam o entendimento do “porquê” de um problema em contextos complexos. Em um trace de ponta a ponta, podemos compreender o tempo de execução em nível de funções, métodos, queries de bancos de dados e clientes HTTP de todas as aplicações que interagem durante o funcionamento de uma transação.

Logs

Logs são registros textuais de eventos que ocorrem em um sistema. São a saída do runtime que representa algo que ocorreu. Um log é um registro imutável, vindo da aplicação que o emitiu, de um evento discreto que ocorreu em um ponto específico no tempo dentro de uma aplicação ou sistema e normalmente vem acompanhado de metadados e um timestamp para comparação e ordenação histórica, podendo ser correlacionado em uma linha do tempo, isoladamente ou com outras aplicações, quando estruturado.

Eles capturam informações detalhadas sobre ações, erros e estados em momentos específicos, como mensagens de erro, dados de transação, informações de payloads ou dados de usuários. Em essência, logs funcionam como um diário detalhado do sistema, permitindo que exista uma investigação funcional de problemas e, diferentemente dos traces, possuem uma característica de troubleshooting funcional, onde nem todo “problema” do software é necessariamente um “erro” ou um “desvio”. Eles nos ajudam a responder perguntas como “O que aconteceu com a transação xxx?”, “O que um usuário específico fez?”, “Qual foi o erro exato que causou a falha desta requisição?”, “Quais foram os parâmetros de uma função quando ela foi chamada e qual foi seu retorno?”.

Níveis de Severidade

Quando tratamos os logs como um “diário detalhado” do sistema, a classificação de severidade é o componente semântico que traduz um fluxo textual qualquer em um componente de telemetria “interrogável”. Os níveis de severidade classificam os registros imutáveis de log em criticidade e contexto, que dizem “o que esse evento significa” e “o que alguém deve fazer a respeito”. Os níveis mais comuns (TRACE, DEBUG, INFO, WARN, ERROR e FATAL/CRITICAL) existem para representar intenções diferentes, não apenas a gravidade do ocorrido. Nesta seção, iremos abordar critérios claros de classificação para cada um deles.

Level	Intenção
TRACE	Rastrear passos internos muito finos para investigação pontual
DEBUG	Explicar decisões internas e facilitar troubleshooting
INFO	Registrar fatos relevantes do fluxo e do domínio
WARN	Registrar um desvio recuperável
ERROR	Falha de operação
FATAL / CRITICAL	Falha terminal em nível de runtime

Nível TRACE

TRACE é o nível de microscopia. Ele existe para quando você precisa observar o caminho exato que o código percorreu, com granularidade alta e verbosa, tipicamente em investigações pontuais, como ordem de decisões internas, branches condicionais, parâmetros intermediários, transformações de payload, detalhes de serialização/deserialização e qualquer nuance que ajude a reproduzir um comportamento que não aparece em logs mais altos, podendo chegar até à verbosidade do protocolo de uma comunicação.

Nível DEBUG

O DEBUG trabalha em nível de diagnóstico. Ele fica abaixo do “contar a história” e acima do “registrar absolutamente tudo”. A intenção do DEBUG é explicar o porquê de uma decisão do sistema, dando visibilidade a variáveis e estados relevantes para troubleshooting, como escolhas de fallback, impressão de parâmetros que levaram uma regra de negócio a seguir por um caminho, identificação de dependências chamadas e seus tempos, composição de requests para serviços downstream, resultados de validações e checkpoints do fluxo que ajudam a localizar o ponto exato de divergência. Geralmente, é utilizado durante períodos de crise para tratar condicionais muito específicas que levam a desvios não tão óbvios, sendo muito útil para sistemas que possuem múltiplos fluxos e uma visão “não tão” determinística em nível de conhecimento do time técnico e de múltiplas condicionais internas.

Nível INFO

O INFO trabalha em um aspecto narrativo da transação. Ele registra eventos relevantes do ponto de vista do sistema e do domínio, de modo que, quando você costura o fluxo por um correlation ID, você consegue ler uma história. O objetivo do INFO é rastrear uma transação de forma consistente e cronológica, como quando uma requisição entra, quem é a entidade principal envolvida, se uma operação foi aceita ou recusada, se um estado mudou, quando um job iniciou e finalizou, quando e como um evento de domínio foi publicado e como e quando uma transação foi concluída, com todas as informações relevantes para tratar um correlationId em nível de um agregado forte.

Nível WARN

O WARN é o nível do desvio com continuidade. É quando algo saiu do ideal, mas o sistema ainda conseguiu seguir adiante, como uma dependência que respondeu de forma mais lenta e um retry foi necessário, um fallback foi acionado, um circuito abriu por proteção, um timeout quase estourou, uma fila começou a crescer, uma validação marginal foi aceita por regra de tolerância, um cache miss inesperado elevou a latência, uma operação precisou degradar para manter a disponibilidade. Um bom WARN é acionável, deve carregar contexto para permitir triagem e pode ser utilizado para confiabilidade, porque ele frequentemente aparece antes do incidente.

Nível ERROR

O ERROR é falha de operação. Aqui, a execução não atingiu o resultado esperado do ponto de vista daquela transação. A requisição falhou e retornou erro, um critério de domínio foi violado e o comando foi rejeitado, uma dependência falhou sem compensação possível, uma transação abortou, uma transação no banco de dados não foi concluída, uma conexão não pôde ser fechada, uma mensagem não pôde ser processada e foi para DLQ, um dado essencial estava ausente ou um estado ficou inconsistente a ponto de impedir continuidade.

Um ERROR precisa ser pensado como um “log de triagem” e deve dizer o que falhou, por que falhou, junto com sua possível causa, onde falhou e em qual componente, e como correlacionar com o resto do fluxo, respeitando correlation IDs.

Nível FATAL

FATAL (ou CRITICAL, dependendo do ecossistema) é falha terminal, aquela que compromete a continuidade do processo ou do serviço. É quando o runtime não consegue seguir, o processo cai, o serviço não inicia, uma configuração essencial é inválida, um recurso crítico não está acessível na inicialização ou uma condição irrecuperável foi atingida e a única resposta segura é encerrar. Como, por exemplo, um NullPointer crítico, uma dependência crítica que não pode ser acessada, falta de variáveis e parametrizações necessárias para iniciar a aplicação, etc. Logs FATAL são geralmente associados a falhas de runtime e impedem a aplicação de funcionar.

Correlação de Logs

A principal função dos logs está no seu nível de detalhe útil. Uma métrica pode mostrar a quantidade de erros dentro de um período específico; porém, um log tem o objetivo de mostrar os outputs da aplicação que indicam quais erros, exceções e em que cenários esses erros aconteceram. Em ambientes cada vez mais distribuídos, com múltiplos serviços dentro de uma mesma transação, podemos estabelecer padrões de campos que se repetem em todos os serviços pelos quais uma determinada transação passa, para que seja possível correlacionar os logs de diversas aplicações e gerar uma “história” de uma transação.

Os logs, para terem valor, precisam contar uma história. Conceitualmente, trabalhamos uma transação como um agregado, e as linhas de log como itens decorrentes desse agregado. Quando bem estruturado, esse padrão nos permite, por meio de identificadores únicos como trace_id, correlation_id, order_id, correlacionar os logs de diversas fontes para explicar como uma determinada transação ocorreu, como o extrato de uma história. Talvez esse seja o cenário em que os logs vão, de fato, gerar todo o seu potencial e justificar seus altos custos de ingestão, armazenamento e retenção.

Estruturação e Indexação de Logs

O maior desafio da ingestão de logs está no custo. Aplicações podem gerar gigabytes ou terabytes de logs por dia, tornando o armazenamento e a análise tarefas muito complexas. Esses logs podem conter uma variedade imensa de informações e valores únicos e despadronizados, como IDs de usuário, IDs de requisição, mensagens de erro detalhadas, stack traces extensos, que são, sim, dados úteis; porém, quando trabalhamos com indexação utilizando os valores desses campos, podemos enfrentar problemas relacionados a performance e custo.

Logs de texto puro são difíceis de analisar em escala. Logs estruturados e padronizados, por exemplo, em JSON, permitem que ferramentas de agregação de logs realizem a indexação por campos específicos mais buscados, além de filtros e agregações, de forma menos custosa computacionalmente e financeiramente. Podemos indexar a partir de correlation IDs, IDs de conta, nível de criticidade e afins. Ter um formato e campos padronizados pode ser, sim, um desafio em ambientes maiores; porém, torna o pilar de logs significativamente mais eficiente em termos de custo de armazenamento, escalabilidade e busca.

Agregados dos Pilares

Além dos três pilares, temos dois outros termos que nos ajudam a agregar confiabilidade aos sistemas: alerting e APM.

Alerting

Alerting, ou alertas, são os mecanismos que transformam os números e dimensões já conhecidos de degradação de um sistema em sinais para intervenção humana. É a disciplina responsável por observar sinais emitidos por logs, métricas, traces ou agregados desses pilares e decidir quando uma condição saiu do campo da simples medição e foi para um campo em que será necessária uma intervenção. É uma forma de saber, de maneira automatizada, que um determinado comportamento do sistema atingiu um nível de risco, desvio ou impacto e que ele merece reação humana ou automatizada.

Do ponto de vista de confiabilidade, o maior valor do alerting está em acelerar feedback loops sobre o comportamento do sistema. Quanto mais cedo um comportamento degradado é percebido pelo time de engenharia responsável, menor tende a ser o tempo de detecção, menor a chance de amplificação do dano para o cliente e maior a possibilidade de contenção do impacto antes de um impacto sistêmico maior para todo o ambiente. Alertas bem definidos reduzem MTTD (Mean Time To Detect), ajudam a proteger o error budget, orientam war rooms e criam um senso de prioridade operacional.

APM

APM, ou Application Performance Monitoring, é a camada de observabilidade voltada a compreender como uma aplicação se comporta durante a execução de trabalho útil, visando entender a experiência do cliente. Enquanto métricas de infraestrutura ajudam a enxergar o estado de recursos alocados, métricas de aplicação ajudam a entender o estado operacional de negócio e os traces ajudam a reconstruir o caminho de uma transação de ponta a ponta, o APM organiza esses sinais ao redor da experiência da própria aplicação, destacando operações, endpoints, dependências, tempos de resposta, throughput, taxas de erro e fragmentos relevantes de execução, para que seja possível observar a saúde do software com mais proximidade do uso real.

O APM tenta responder perguntas como “quais operações estão mais lentas agora?”, “quais delas regrediram após uma mudança?”, “quais endpoints concentram mais erro?”, “quais dependências estão consumindo mais tempo da transação?”, “onde estão os gargalos de latência?”, “qual parte do fluxo ficou mais cara sob carga?” e “quais jornadas estão sofrendo de forma mais perceptível?”. Ele busca agregar todos os sinais de observabilidade sob um guarda-chuva de experiência de uso.

Service Levels

Os Service Levels são o principal framework de mercado para engenharia de confiabilidade. Tendo sua origem na engenharia da Google, eles nos dão direcionamentos simples de como transformar métricas técnicas em “estrelas-guia” de produto, que são capazes de ser interpretadas por diversos níveis de uma empresa. Na prática, tornam-se a interface comum de linguagem entre engenharia e negócio, onde encontramos um acordo claro sobre qual é a experiência mínima aceitável, quais são as tolerâncias operacionais e qual é o custo de sustentar esse patamar desejado.

Um sistema pode ter dashboards extremamente detalhados e, ainda assim, operar no escuro se não houver um referencial explícito de “normalidade” e “aceitável” para a jornada do usuário, e é exatamente esse vácuo que SLA, SLO, SLI e Error Budget preenchem em sistemas maduros.

SLI - Service Level Indicator

O SLI, ou Service Level Indicator, é o indicador mensurável que materializa o SLA e o SLO. O SLI é o dado que será observado, como, por exemplo, Availability/Uptime, Latency, Throughput, Error Rate, Saturation, Recovery Time, etc. Ele indica qual será a métrica observada em ambos os casos. A escolha e a maturidade de um SLI devem ser criteriosas e evolutivas, acompanhando os times de engenharia e os próprios SLOs e SLAs. Podem tanto ser métricas técnicas, como as citadas, quanto métricas de negócio ou específicas de um produto, como, por exemplo, acurácia de um modelo, taxas de aprovação de transações, redução de fraudes, etc.

SLA - Service Level Agreement

O SLA, ou Service Level Agreement, é o indicador mais importante em nível de cliente. O SLA é um compromisso contratual de nível de serviço, normalmente formalizado com clientes, áreas internas ou parceiros. Esse compromisso atua na esfera contratual de um provedor de serviço, seja ele interno ou externo.

Quando contratamos algum serviço, seja ele IaaS, SaaS ou PaaS, ele está inerente a um contrato de disponibilidade. Quando esse contrato é quebrado, podem existir consequências jurídicas para o prestador do serviço. Por isso, SLA não é o lugar para “fidelidade técnica”, e sim para accountability. Ele tende a ser mais estável, mais conservador e menos granular, porque precisa ser mensurável, auditável e defensável. Ele está além de uma métrica do time técnico, que deve trabalhar com margens menores que o SLA como objetivo operacional.

Um SLA está inerente a tudo que permeia a operação do cliente final. Pode ser considerado a partir de disponibilidade, tempo de resposta, tempo de recuperação de desastre, etc. Os SLAs podem ser definidos como “ter 99.99% de uptime, 99.9% de disponibilidade nas requisições, responder uma transação de cartão de crédito em menos de 600 ms, ter um data loss de no máximo 2 h em RPO, ter um tempo de recuperação de falhas de até 1 h”, etc.

Quando estabelecemos SLAs de disponibilidade, a definição dessa métrica nunca deve ser 100%, pois qualquer variação ou desvio pode comprometer o contrato. Ao invés disso, adicionamos “9’s”, como, por exemplo, 99%, 99.9%, 99.99%, etc., mas nunca 100%.

Os SLAs precisam ser declarados e conhecidos por todas as camadas do produto — times técnicos, negócio, marketing e suporte — e devem ter um escopo claro, como disponibilidade mensal, disponibilidade anual, disponibilidade diária, tempos de resposta, etc. O SLA, inclusive, pode ser granular em nível de serviço ou feature do sistema, medido de forma isolada em uma jornada, endpoint, etc.

SLO - Service Level Objective

O SLO, Service Level Objective, é o seu “contrato interno” de confiabilidade. O SLO é, de fato, uma métrica inerente ao time técnico: o critério que o time de engenharia utiliza para operar, decidir e assumir riscos.

Um SLO pode ser “responder em menos de 600 ms em p99 e 500 ms em p95”, “garantir replicação de dados em três fatores”, “ter uma média diária de error rate abaixo de 1%” ou herdar diretamente os critérios do SLA.

Caso os SLIs dos SLOs sejam os mesmos do SLA, eles devem ser mais restritivos que o SLA, pois também funcionam como uma blindagem técnica do contrato. Por exemplo, se o SLA estabelecido por contrato é de uma disponibilidade mensal de 99.9%, com um tempo de resposta de p99 de 800 ms, o SLO precisa ser mais restritivo, considerando, por exemplo, 99.95% de disponibilidade e um p99 de 500 ms. A longo prazo, o objetivo de um SLO é tornar-se o SLA do produto, enquanto o time técnico continua elevando o nível de exigência para atingir excelência operacional.

Error Budget

O Error Budget é o orçamento de erros associado a um contrato. Se o SLO define “quanto erro é aceitável”, o Error Budget define “quanto erro você ainda pode consumir antes de entrar em risco”. Se nosso SLO é 99.95% de disponibilidade e nossos SLIs apontam para 99.98% de disponibilidade, isso significa que temos 0.03% de margem para erros dentro do sistema.

O objetivo do Error Budget, além de mostrar o quanto de margem ainda temos para errar dentro das metas técnicas, é funcionar como um indicador de feedback loop dentro das releases de software. Quando o budget está saudável e possui margens consideráveis, você pode acelerar mudanças e deploys em produção. Ao contrário disso, quando o budget está sendo consumido e está muito próximo de atingir o limite, você desacelera, prioriza correções, reduz blast radius e aumenta o rigor de release e revisões. Se o budget estourou, você congela releases não essenciais, direciona capacidade para estabilidade e conduz war rooms de observabilidade e acompanhamento.

Frameworks de Mercado

Antes de entrar nos frameworks de mercado, vale estabelecer o porquê de eles existirem e qual problema real resolvem. Pois, a princípio, perante vários cases de uso complexos, com múltiplos níveis de observabilidade e operação, em um primeiro momento, eles podem parecer bem simplistas. Mas não são. O objetivo dos frameworks de mercado é fornecer “estrelas-guia” simplificadas para os times de engenharia e produto. Dentro de produtos de tecnologia, a maior parte das discussões operacionais degrada por dois caminhos previsíveis: ou o time se afoga em centenas de métricas desconexas, sem conseguir distinguir sintoma de causa, ou se apega a uma ou duas métricas “fáceis”, como CPU média, 5xx e latência média, e toma decisões erradas com muita confiança.

O objetivo de frameworks como Four Golden Signals, RED e USE é sugerir métricas simples e facilmente compreensíveis, que vão atuar como bússolas de navegação do sistema em produção. Usá-los, de forma alguma, descaracteriza a necessidade de observar dimensões mais detalhadas; apenas simplifica o entendimento da saúde do serviço por meio de métricas direcionadas.

USE Method

O USE Method surge no contexto de engenharia de performance de sistemas, popularizado e formalizado por Brendan Gregg no artigo “Thinking Methodically about Performance”, como uma estratégia de checagem sistemática e padronizada da “saúde” de recursos físicos alocados.

O objetivo do Método USE é dar visibilidade a cada recurso, como CPU, memória, disco, rede e outros, como filas e pools, e observá-los em três dimensões principais: Utilization, Saturation e Errors. Esses recursos podem ser tanto recursos alocados para aplicações dentro de containers ou servidores quanto recursos de suas dependências, como databases, caches, filas, etc.

Ele descreve o USE como um método para iniciar uma investigação de queda de performance de forma simples e objetiva, monitorando sinais vitais e identificando gargalos sistêmicos com rapidez.

Utilization (Utilização)

A Utilization é quanto do recurso está sendo consumido em um intervalo de tempo. Em CPU, pode ser o percentual de tempo em execução ou o percentual utilizado em relação ao alocado. Em memória, pode ser o uso em relação ao provisionado. Em disco, pode ser busy time / throughput em relação ao limite de IOPs. Em rede, pode ser a bandwidth consumida em relação ao total permitido. Em pools, pode ser conexões em uso em relação ao limite do banco, etc. Utilization é um indicador de carga e tendência. Ele é útil para capacity planning, detecção de regressões e para “contextualizar” a saturação.

Saturation (Saturação)

A Saturação é o estado de superalocação de um recurso computacional, como CPU, memória, thread pools e connection pools. Geralmente, é monitorada pela ocupação ou pressão sobre o recurso, e não apenas pela utilização percentual. Por exemplo, quantos processos estão aguardando CPU (run queue) ou quantas requisições estão enfileiradas aguardando processamento. Quando esse recurso começa a degradar por operar próximo de sua capacidade total, entendemos que ele está saturado.

Em CPU, a saturação pode aparecer como run queue (processos esperando CPU), throttling de cgroup e o comumente utilizado load average. Em memória, pode aparecer como swapping, garbage collector em excesso, falhas de alocação, etc. Em disco, aparece como filas de I/O, iowait, latência de I/O, backlog de flush. Em rede, aparece como drops, retransmissões, filas no kernel, etc.

Errors (Erros)

Os Errors no USE são falhas diretamente associadas ao recurso monitorado. Em CPU, falhas por starvation ou erros de scheduling. Em memória, OOMKills, allocation failures, crashes por falta de heap, evictions. Em disco, I/O errors, timeouts, corrupções, falhas de mount. Em rede, connection resets, TLS handshakes falhando por exaustão de recursos, packet loss, DNS failures. Em pools, “too many connections”, “thread pool exhausted”, “queue full”, “rate limit exceeded”. O valor desses erros é o sinal necessário para indicar que o recurso provisionado e alocado não está sendo suficiente para suportar a quantidade de trabalho.

RED Method

O RED Method nasce de uma necessidade equivalente à do USE, porém voltada para serviços e aplicações. Como vimos, o USE foi concebido para recursos e infraestrutura, enquanto microserviços demandam uma visão de métricas direcionadas à experiência e ao comportamento do serviço em produção, por meio de três dimensões básicas. O termo é associado a Tom Wilkie e à Grafana, por meio de diversos artigos e apresentações técnicas direcionadas à instrumentação e ao monitoramento de serviços, principalmente em sistemas distribuídos.

O RED busca simplificar os sinais vitais mais importantes para qualquer aplicação web, sendo eles Rate, Errors e Duration. Em caso de dúvidas sobre o que monitorar, a base será essa.

Rate (Request Rate / Throughput)

O Rate representa a pressão de demanda sobre o serviço e a sua capacidade efetiva de processar essa demanda. Ele evidencia quantas transações estão chegando ao sistema em um determinado intervalo de tempo, como “transações por segundo”, “requests por minuto”, etc. Ele representa o quanto o sistema está sendo requisitado pelos clientes.

Essa métrica pode ser medida em um contexto global do sistema, mas, além disso, deve ser medida de forma granular também em nível de endpoint e funcionalidade, como requisições por segundo por rota, por operação (GET/POST), por tenant, por região, por versão (canary vs stable), etc.

O request rate é a primeira métrica a ser monitorada, pois o aumento do rate de uma aplicação ou funcionalidade pode acarretar saturação e aumento proporcional de erros e filas internas, caso o sistema não opere com escalabilidade horizontal de forma responsiva. Ele também nos ajuda a identificar picos e tendências de uso do sistema, que podem gerar insights valiosos para capacity planning e aplicação de estratégias de autoscaling.

Errors (Error Rate)

Os Errors estão diretamente ligados ao request rate, pois têm o objetivo de demonstrar a porcentagem das requisições que estão chegando ao sistema e falhando. A métrica tem o critério de medir falhas observáveis do ponto de vista do consumidor, mas só é útil se “erro” for definido de forma semântica.

É comum que essa semântica considere apenas erros “HTTP 5xx”. Isso é insuficiente por dois motivos: primeiro, porque 4xx pode representar degradação com base em desvios, como autenticação falhando por clock skew, validações quebradas por mudança de contrato, “429” por rate limit excessivo, etc. Em confiabilidade, erro é tudo aquilo que viola a expectativa de sucesso do consumidor: falha de autorização indevida, timeout, resposta inválida, inconsistência, idempotência quebrada, duplicidade e até sucesso tardio, quando o usuário já desistiu.

Resumindo, todos os códigos de erro, sejam eles 4xx ou 5xx, devem ser monitorados e considerados; porém, nem todos precisam ser tratados como SLOs, apenas observados em nível de serviço.

Duration (Request Duration / Latency)

Duration mede o tempo para completar uma operação do ponto de vista do consumidor. É o critério mais fácil de medir e também o mais fácil de medir de forma incorreta. O primeiro ponto de atenção é o uso exclusivo da média de latência em sistemas complexos. A média pode ser distorcida quando há problemas de tempos de resposta em uma distribuição de cauda longa, e as caudas são onde a experiência degrada, os timeouts disparam e os retries começam a amplificar a carga. Duration precisa ser analisada em percentis (p50/p95/p99) e, idealmente, com histogramas para observar a forma da distribuição. Quando aplicada também em nível granular por métodos ou endpoints, podemos entender quais funcionalidades estão apresentando desvios de tempo de resposta, acelerando o troubleshooting e o tempo de recuperação.

Four Golden Signals

Os Four Golden Signals são uma forma direcionada e simplificada de descrever a saúde operacional de um sistema user-facing, evitando o caos de métricas infinitas. O conceito foi popularizado pela literatura do Google sobre Site Reliability Engineering e tem o objetivo de realizar uma recomendação explícita de quatro métricas principais, os Sinais de Ouro. Esses quatro sinais têm o objetivo, inclusive, de orientar a definição de SLOs de forma simples.

O objetivo é padronizar métricas em escopos pequenos, médios e grandes, evitando o fenômeno de “monitoramento por acúmulo”, em que times passam a colecionar uma quantidade muito grande de métricas e dashboards, mas, sem um modelo mental coeso, acabam incapazes de responder rapidamente a perguntas simples como “o sistema está saudável do ponto de vista do usuário?”, “quais sistemas estão degradados agora?”, etc.

Os quatro sinais são Latency, Traffic, Errors e Saturation.

Latency

A Latência nos Four Golden Signals corresponde ao tempo que um sistema, transação ou funcionalidade leva para responder a uma requisição. No modelo, isso inclui tanto respostas bem-sucedidas quanto respostas com erro, porque, para a experiência do usuário, “rápido e errado” ainda é um comportamento observável relevante, assim como “lento e correto”.

A latência, assim como em outros frameworks de mercado, não deve considerar apenas a média e precisa levar em consideração a leitura de percentis, que podem dar visibilidade a comportamentos ocultos de outliers, como p99, p95, p90, p50, etc.

Traffic

O Traffic, tráfego ou throughput, busca dar visibilidade à quantidade de solicitações que o sistema está recebendo dentro de um intervalo de tempo e pode ser ilustrado como requisições por segundo, transações por segundo, queries por segundo, bytes, mensagens, etc., representando o “quanto de trabalho” está chegando ao sistema.

Aqui, o objetivo também é dar visibilidade a comportamentos causais, como quando o tráfego sobe e é necessário separar crescimento legítimo de uso do sistema de demandas de amplificação por mecanismos internos, como retries, fanout, reprocessamento, loops, cache miss em massa ou abuso indevido do serviço.

Errors

Os Errors são a taxa de falhas percebidas em relação ao Traffic. Na definição do livro do Google, erros podem aparecer como códigos de erro internos, como 5xx, mas também como falhas explícitas de protocolo e falhas semânticas de resultado, dependendo do que faz sentido para o sistema. A princípio, também é necessário monitorar erros do cliente (4xx) para entender comportamentos e desvios.

Saturation

Saturation é um sinal de proximidade de esgotamento dos recursos provisionados para a aplicação. Responde o quanto o sistema está “no limite” de algum recurso crítico e, principalmente, o quanto trabalho está se acumulando porque o recurso não consegue acompanhar. Por exemplo, o quanto do tráfego está se aproximando dos níveis de rate limit estabelecidos na API, ou o quanto o uso das CPUs da aplicação está próximo de um limite de risco, etc.

Referências

What is observability?

What are SLOs, SLIs, and SLAs?

Time, Clocks, and the Ordering of Events in a Distributed System

Conceitos OpenTelemetry - Ezzio Moreira

What is OpenTelemetry?

Monitoring Distributed Systems

Service Level Objective

Thinking Methodically about Performance

4 SRE Golden Signals (What they are and why they matter)

USE and RED Method

The RED Method: How to Instrument Your Services

Monitoring Methodologies: RED and USE

Monitoring and Observability With USE and RED

SLOs: a guide to setting and benefiting from service level objectives

What Are Feedback Loops?

SLI’s, SLA’s e SLO’s :: Não sabe por onde começar com suas métricas? Comece por aqui!

The RED Method: How to Instrument Your Services

System Design - Single Point of Failure, Disaster Recovery e Continuidade Operacional

Tue, 10 Mar 2026 00:00:00 +0000

Em sistemas distribuídos, a confiabilidade é um dos temas de maior importância na construção de serviços. Existem infinitas possibilidades que podem acarretar alta disponibilidade ou problemas de disponibilidade em um sistema, e uma das formas de identificar oportunidades de otimização de resiliência, além de encontrar gargalos, é identificar os Pontos Únicos de Falha entre os componentes.

Neste rápido capítulo, vamos explorar de forma simples esse conceito e treinar o olhar crítico para identificar possíveis riscos e oportunidades. Vamos aproveitar também o gancho para elaborar um próximo passo: detalhar as estratégias de Disaster Recovery de mercado.

Definindo um Single Point of Failure

Um Single Point of Failure (SPoF), ou “Ponto Único de Falha”, é um termo usado para se referir a qualquer componente, serviço ou recurso centralizado cuja falha provoca a indisponibilidade total ou parcial de um ou mais sistemas. Um Ponto Único de Falha pode representar um Banco de Dados, um Balanceador de Carga, um API Gateway, um broker de mensageria ou até mesmo outro microserviço que, em caso de queda, não possua nenhum caminho alternativo para que as requisições sejam estabelecidas.

Imagine que uma cidade possua como única forma de acesso uma ponte. Essa ponte seria, no mundo real, um ponto único de falha. Por mais que ainda exista a possibilidade de acesso por barco, helicóptero ou balsa, não seriam todas as pessoas que teriam acesso, e a entrada e saída, bem como o envio de recursos e afins, ainda estariam gravemente impactados. Isso seria um Ponto Único de Falha que gera uma indisponibilidade total ou parcial de acesso à região.

São raros os sistemas que não possuam nenhum tipo de Ponto Único de Falha. A partir disso, podemos assumir algumas premissas, como a de que, quando um SPoF falha, o sistema pode entrar em modo degradado, no melhor dos casos, ou parar completamente, no pior. Logo, quanto maior a responsabilidade de um componente, maior o impacto de sua falha caso não existam Fluxos de Fallback. Outra característica importante é que recuperações manuais ou rebuilds desses componentes levam tempo e podem causar perdas significativas.

Identificando Single Points of Failure

Identificar os SPoF de algum ambiente pode parecer extremamente trivial, porém pode se tornar uma tarefa árdua e de grande esforço corporativo em ambientes grandes e de larga escala, pois precisamos mapear quais são as funcionalidades mais críticas, documentar cada serviço, seus clusters, nodes, servidores, databases, componentes de rede, brokers de eventos e mensagens e até fornecedores, sem falar dos times responsáveis e das formas de acionamento de cada um deles.

Durante esse mapeamento, é necessário desenhar um “fluxo feliz” de cada transação dessas funcionalidades críticas, mapear todos os atores, desde a requisição de fato até a resposta para o usuário. Em seguida, é necessário inspecionar quais desses componentes não possuem réplicas (/replicacao/), implementam padrões de resiliência (/resiliencia/), fallbacks e mecanismos que consigam assumir esses fluxos alternativos automaticamente. São nesses atores que são encontrados candidatos a se tornarem pontos únicos de falha em um fluxo crítico.

A identificação de “Pontos Únicos de Falha” não é uma tarefa pontual ou fácil; necessita de constante revisão arquitetural e esforço corporativo para que seja realmente efetiva, ainda mais se começarmos a descer o nível de abstração de virtualização, networking, replicação entre provedores etc.

Lidando com Single Points of Failure

Existem estratégias comuns que podem nos auxiliar a corrigir e, principalmente, evitar a criação de SPoFs; nesta seção, iremos identificar, de forma macro, como endereçar algumas delas. Lidar com SPoFs não significa simplesmente duplicar componentes indiscriminadamente. O objetivo central é reduzir o blast radius, aumentar a previsibilidade sob falha e diminuir o tempo de recuperação. Toda estratégia de mitigação envolve trade-offs entre custo, complexidade, latência e consistência.

A eliminação completa de SPoFs é praticamente impossível em sistemas reais, especialmente quando consideramos limitações físicas, econômicas e organizacionais. A discussão deve considerar o custo-benefício da redundância perante as necessidades e o momento da empresa. Às vezes, é muito mais benéfico aceitar a falha momentânea diante de um incidente de infraestrutura global do que lidar com os custos extensivos de manter múltiplos ambientes e redundâncias para lidar com desastres momentâneos.

Design Stateless de Aplicação

Aplicações que mantêm estado local tendem a criar afinidade entre cliente e instância, dificultando a redistribuição de carga em caso de falha. Sessões armazenadas em memória, caches locais indispensáveis ou fluxos que dependem de contexto interno tornam a substituição de instâncias mais lenta e arriscada. Ao adotar um design stateless, o estado é externalizado para camadas distribuídas e resilientes, permitindo que qualquer instância processe qualquer requisição. Isso reduz significativamente a fricção durante eventos de falha, pois a remoção de uma instância não implica perda de contexto.

No entanto, externalizar o estado desloca a responsabilidade de resiliência para a camada de persistência. Bancos de dados, caches distribuídos e sistemas de armazenamento passam a concentrar o risco anteriormente diluído na aplicação.

Redundância e Replicação Ativa

Uma redundância ou replicação ativa é um modelo no qual todas as instâncias e réplicas de um serviço trabalham simultaneamente para receber e processar as requisições da carga de trabalho. Resumidamente, nenhuma das réplicas tem como objetivo ficar ociosa aguardando uma falha geral para que assuma o processamento primário das requisições. Esse arranjo arquitetural pode ser encontrado em réplicas de aplicações atrás de balanceadores de carga, onde todas são verificadas quanto à integridade e recebem carga quase que uniformemente mediante solicitação do serviço, ou em sistemas de mensageria, onde todas as réplicas estão conectadas aos tópicos/filas e podem receber mensagens e eventos para processar. No geral, esse tipo de arquitetura, quando trabalhada sem estado, permite que, na falha eventual de pequenas quantidades de réplicas, o sistema continue operando e consiga se recuperar sem gerar grandes danos (ou, de preferência, nenhum dano) à experiência do cliente.

Na replicação ativa, todas as instâncias operam simultaneamente processando carga real. Esse modelo dilui o impacto da falha de uma ou mais réplicas, pois as demais continuam absorvendo requisições. Balanceadores de carga distribuindo tráfego uniformemente e consumidores paralelos processando mensagens em tópicos são exemplos mais básicos dessa abordagem.

Esse modelo também pode ser encontrado em réplicas de leitura de bancos de dados que possuam estado transacional, contendo todos os dados escritos nas réplicas primárias. Além de possuir um viés de disponibilidade, onde essa réplica é capaz de assumir o papel de escrita em caso de falha na réplica principal, pode exercer funcionalidades ativas na segregação de escrita e leitura em diferentes instâncias.

Esse modelo, entretanto, exige mecanismos consistentes de sincronização de dados, especialmente quando há escrita concorrente. Em bancos de dados com réplicas de leitura promovíveis, a replicação ativa pode tanto aumentar a disponibilidade quanto melhorar a performance por meio da segregação de leitura e escrita.

Redundância e Replicação Passiva

Na replicação passiva, apenas uma instância atua como primária, enquanto outra permanece em standby, aguardando falha para assumir. Esse modelo reduz a complexidade quando comparado ao ativo-ativo somente em termos de replicação e latência, mas introduz dependência crítica nos mecanismos de detecção e promoção e nos faz assumir que precisamos ter ambientes altamente replicados que estejam disponíveis para assumir um chaveamento brusco ou gradual, sem piorar a experiência do cliente ou criar inconsistências irrecuperáveis.

Se a falha não for detectada rapidamente ou se a promoção for manual e lenta, o tempo de indisponibilidade pode ser significativo.

Failover Automático

Failover automático depende de monitoramento confiável, critérios claros de decisão e mecanismos transparentes de redirecionamento de tráfego. A estratégia é empregar mecanismos como Circuit Breakers ou feature toggles que saibam detectar padrões de falha do sistema e realizar “chaveamentos” para fluxos alternativos. Esses fluxos podem tanto envolver o redirecionamento do tráfego para uma zona passiva, a desativação de uma zona ativo-ativa quanto assumir sistemas secundários de contingência que cumpram os mesmos objetivos com taxas menores, enfileiramentos maiores ou parceiros secundários.

Disaster Recovery

O Disaster Recovery é um conjunto de estratégias, processos, arquiteturas e automações projetadas para restaurar sistemas após eventos de grande impacto que ultrapassam o escopo de falhas locais corriqueiras da aplicação. Desastres não são falhas normais. São eventos de grande escala que ultrapassam os limites aceitáveis de operação de um produto, como, por exemplo, quedas de Cloud Providers, incidentes climáticos, downtimes de componentes críticos e centralizados etc.

Diferentemente da mitigação de SPoFs, que normalmente atua em nível de componente, o Disaster Recovery opera no nível de produto, com escopo amplamente sistêmico e até mesmo regional. Um SPoF pode derrubar um serviço específico. Um desastre pode comprometer um datacenter inteiro, uma região de nuvem ou até múltiplos serviços simultaneamente. Incêndios, falhas elétricas, corrupção massiva de dados, erros humanos em larga escala, ataques cibernéticos ou falhas generalizadas de provedores são exemplos comuns. Existem alguns modos de operação de DR que podemos avaliar para implementar conforme as necessidades do cenário.

Ativo-Ativo

Arquiteturas ativo-ativo permitem que múltiplas regiões ou clusters recebam tráfego simultaneamente, elevando significativamente a disponibilidade global. Contudo, essa abordagem amplia drasticamente a complexidade da consistência distribuída.

Modelos multi-master exigem estratégias explícitas de resolução de conflitos, como last write wins ou estruturas convergentes como CRDTs. A disponibilidade aumentada vem acompanhada de maior esforço operacional e complexidade cognitiva. Em muitos casos, o ativo-ativo distribui o risco, mas não o elimina; apenas torna o impacto menos concentrado.

Ativo-Passivo

O modelo ativo-passivo mantém uma região primária processando tráfego, enquanto outra permanece preparada para assumir em caso de desastre. Essa abordagem equilibra simplicidade e resiliência. Embora menos complexa que o ativo-ativo, ainda protege contra falhas regionais significativas.

Esse modelo equilibra custo e resiliência, sendo amplamente utilizado em ambientes regulados ou que exigem consistência forte. No entanto, a sincronização contínua de dados precisa ser validada regularmente e, no momento do chaveamento, a região passiva pode lidar com consistência eventual de dados até que os mecanismos de sincronização estejam atualizados.

Pilot Light (Luz Piloto)

No modelo Pilot Light, apenas os componentes essenciais permanecem ativos na região secundária, como bancos de dados replicando continuamente. Os demais recursos são provisionados sob demanda durante o desastre. Essa estratégia reduz custos operacionais, mas aumenta o tempo de recuperação, pois parte da infraestrutura precisa ser ativada e escalada após o evento.

O modelo Pilot Light assume explicitamente que desastres regionais são eventos raros e que parte da infraestrutura pode ser provisionada sob demanda caso ocorram. Ele reduz o custo operacional, mas aumenta o tempo de recuperação. O sucesso dessa estratégia depende fortemente do nível de automação para acioná-la em caso de falhas, necessitando de uma quantidade significativa de testes e simulações de desastres para validar que o warm-up dos recursos em standby será provisionado de forma suficiente e em tempo hábil para o chaveamento do tráfego, sem impactar excessivamente a experiência de uso do cliente.

Métricas e KPIs de Recuperação

Quando estabelecemos que tanto a eliminação de desastres quanto a inexistência completa de Single Points of Failure são, de fato, impossíveis, o trabalho de projetar sistemas de alta disponibilidade operacional passa a ser sobre criar camadas de resiliência e contenção desses eventuais impactos. Nesse contexto, precisamos metrificar a efetividade das estratégias empregadas ao longo do tempo para comparações, a fim de identificar se estamos degradando ou melhorando a experiência do sistema.

Para elaborar essa discussão, precisamos sair do campo qualitativo das estratégias e nos focar nos aspectos quantitativos, governando as decisões por métricas. As principais métricas que iremos abordar são MTTD, MTBF, MTTR, RTO e RPO. Elas não são independentes; formam um sistema matematicamente interligado que determina disponibilidade, risco e impacto das falhas de sistemas de forma mais profissional e embasada.

MTTD - Mean Time to Detect

O MTTD (Mean Time to Detect) representa o tempo médio entre o início de uma falha e sua detecção pelo sistema ou equipe operacional. É uma métrica que mede o tempo médio que leva para uma equipe ou sistema identificar que um incidente ou falha ocorreu. Imagine um serviço de e-commerce que sofre um problema em sua base de dados, causando lentidão nas transações dos clientes. O MTTD seria o tempo desde o início dessa lentidão até o momento em que a equipe responsável é acionada para intervenção.

O cálculo do MTTD é a soma das diferenças entre a detecção e o início dos incidentes ao longo do tempo, dividida pelo número de incidentes no mesmo período.

\begin{equation} MTTD = \frac{\text{Diferença Entre O Início e a Detecção dos Incidentes}}{\text{Número de Incidentes}} \end{equation}

Por exemplo, temos a tabela dos últimos incidentes de uma aplicação durante um período:

Hora de Início	Hora da Detecção	Tempo Total
11:00 AM	12:00 PM	60 min
05:12 AM	05:30 AM	18 min
03:40 PM	04:00 PM	20 min
10:12 PM	10:33 PM	21 min
09:11 AM	10:02 AM	51 min

Podemos calcular o MTTD do sistema da seguinte forma:

\begin{equation} MTTD = \frac{(60 + 18 + 20 + 21 + 51)}{5} \end{equation}

\begin{equation} MTTD = \text{34 minutos} \end{equation}

Ele está diretamente ligado ao investimento de tempo e inteligência de engenharia em observabilidade sistêmica, contemplando logs, métricas, traces e alertas que garantam que o time esteja sempre monitorando os indicadores corretos e recebendo notificações com antecedência.

Um MTTD alto indica ausência de observabilidade em pontos importantes da solução. Em sistemas distribuídos complexos, falhas raramente são binárias no âmbito de disponível e indisponível, e sim degradam progressivamente, como aumentos de latência, formação de filas internas, saturação, erros intermitentes e timeouts em cascata. Um MTTD baixo é importante, pois quanto mais rápido uma falha é detectada, mais cedo o processo de recuperação pode ser iniciado.

MTTR - Mean Time to Repair

O Mean Time to Repair (MTTR) é o tempo médio necessário para reparar uma falha e restaurar o sistema à operação normal de forma completa. É uma métrica que acompanha diretamente o MTTD. Em estratégias de recuperação de desastres, minimizar o MTTR é o indicador que traduz operacionalmente se estamos trabalhando corretamente os pontos de falha e reduzindo o impacto no usuário final.

O cálculo do MTTR é a soma das diferenças de tempo entre a detecção e a recuperação dos incidentes, dividida pelo número de incidentes no mesmo período.

\begin{equation} MTTR = \frac{\text{Diferença Entre a Detecção e a Resolução dos Incidentes}}{\text{Número de Incidentes}} \end{equation}

Por exemplo:

Hora da Detecção	Hora da Recuperação	Tempo Total
12:00 AM	01:30 AM	90 min
05:30 AM	07:15 AM	105 min
04:00 PM	06:12 PM	132 min
10:33 PM	10:55 PM	22 min
11:02 AM	02:15 PM	193 min

Podemos calcular o MTTR do sistema da seguinte forma:

\begin{equation} MTTR = \frac{(90 + 105 + 132 + 22 + 193)}{5} \end{equation}

\begin{equation} MTTR = \text{108 minutos} \end{equation}

Um MTTR baixo significa que o time de operação sabe lidar com as falhas conhecidas e restabelecer os serviços de forma eficiente e coordenada rapidamente. Um MTTR alto significa o inverso: que os times levam muito tempo para restabelecer os serviços, seja pela complexidade operacional envolvida, seja pela inexistência de processos bem definidos e documentados para recuperação de falhas.

Para reduzir o MTTR, o time de engenharia precisa focar em documentação, runbooks, automações de tarefas de recuperação e self-healing, scripts de rollback, reinício de serviços, as mesmas ferramentas de diagnóstico que dão suporte ao MTTD, além de processos de escalonamento de incidentes e comunicações corporativas fortes e disseminadas culturalmente.

MTBF - Mean Time Between Failures

O Mean Time Between Failures (MTBF) é uma métrica que indica o tempo médio esperado entre duas falhas de um mesmo sistema. Basicamente, é o intervalo de tempo entre dois acionamentos graves. É um dos indicadores de confiabilidade mais importantes, pois, quanto maior o MTBF, maior a confiabilidade do sistema em questão.

Diferentemente das métricas anteriores, o MTBF considera o intervalo entre o término de um incidente e o início do próximo.

\begin{equation} MTBF = \frac{\text{Soma dos Tempos de Operação Saudável}}{\text{Número de Falhas}} \end{equation}

Ordem	Recuperação Anterior	Próximo Início	Intervalo
1	07:15 AM	09:11 AM	116 min
2	02:15 PM	03:40 PM	85 min
3	06:12 PM	10:12 PM	240 min
4	10:55 PM	05:12 AM (dia seguinte)	377 min

Podemos calcular o MTBF do sistema da seguinte forma:

\begin{equation} MTBF = \frac{(116 + 85 + 240 + 377)}{4} \end{equation}

\begin{equation} MTBF = 204{,}5 \text{ minutos} \end{equation}

Um MTBF alto sugere que um sistema é mais estável e exige menos intervenções do time técnico em ambiente produtivo. Um MTBF baixo sugere que existem muitos componentes frágeis ou estratégias que precisam de revisão. Esta métrica é fundamental para o planejamento de capacidade, manutenção preventiva e avaliação da qualidade de hardware e software.

RTO - Recovery Time Objective

O Recovery Time Objective (RTO) é o tempo máximo aceitável que um sistema ou serviço pode ficar indisponível após a detecção de uma falha ou desastre. Esse número tem interesse contratual, pois vai determinar quais ferramentas, estratégias e investimentos serão necessários para garantir a continuidade operacional. Soluções mais rápidas de recuperação geralmente são mais caras e complexas de implementar. Um RTO de “zero” significa que o sistema deve ser recuperado instantaneamente e os clientes não têm apetite para falhas em nenhum aspecto, o que é extremamente difícil e caro de alcançar. Atingir o RTO envolve projetar sistemas com redundância, automação de failover, backups eficientes e processos de restauração bem testados, identificando e criando fallbacks para o maior número possível de SPoFs conhecidos.

Uma aplicação bancária transacional pode ter um RTO de 1 hora, significando que, após qualquer tipo de desastre, ela deve estar completamente operacional em, no máximo, 60 minutos. Já um blog pessoal, site institucional ou pequenos e-commerces podem ter um RTO de 12, 24 ou 48 horas, pois o impacto de uma indisponibilidade, por mais que exista, é menor. Os dois exemplos guiariam, por exemplo, o nível de investimento e engenharia que deve ser inserido na estratégia. Garantir ambientes celulares, múltiplos shardings, arquiteturas multi-datacenter, multi-região e multi-cloud em sistemas que possuem RTOs menos exigentes não faz sentido financeiramente. Já no cenário oposto, pode justificar o investimento e a complexidade.

RPO - Recovery Point Objective

O RPO (Recovery Point Objective) define a quantidade máxima de dados que pode ser perdida após um desastre. Normalmente, é uma métrica relacionada à defasagem entre os dados primários e os backups e aos lags de replicação. Ela, assim como o RTO, é uma métrica contratual. Essa métrica guia o nível de investimento necessário em backups e estratégias de replicação de dados. Se backups ocorrem a cada 12 horas, tenho um RPO de 12 horas. Se possuo 5 minutos de lag de replicação entre os dados de um sistema primário e secundário, meu RPO é de 5 minutos.

Um RPO baixo ou próximo de zero significa que a perda de dados deve ser mínima ou inexistente, exigindo soluções de replicação contínua ou backups muito frequentes. Um RPO de “zero” normalmente implica replicação síncrona ou soluções de banco de dados distribuídos altamente consistentes entre todas as zonas e regiões secundárias do dado.

O nível de criticidade do dado guia a necessidade do RPO. Sistemas financeiros, transacionais, hospitalares ou de aviação precisam ter acordos de RPO mais criteriosos. Sistemas como redes sociais, sistemas institucionais e afins podem lidar com opções mais flexíveis.

Referencias

Single Point of Failure (SPOF) in System Design

Single point of failure

What is a single point of failure?

Why a Single Point of Failure (SPOF) is Scary

Understanding Single Point Failures: A Guide to System Resilience

Qual a diferença entre MTTR, MTBF, MTTD e MTTF?

What Is MTTD? The Mean Time to Detect Metric, Explained

What Is MTTD (Mean Time to Detect)? A Detailed Explanation

System Design - Cell-Based Architecture

Mon, 02 Mar 2026 00:00:00 +0000

A arquitetura celular é um tema particularmente especial pra mim, olhando para o próximo passo de sistemas distribuídos de ambientes críticos; o tema é particularmente fascinante.

Esse foi o tema da minha pesquisa de mestrado, e depois de bastante tempo tentando consolidar o tema academicamente, decidi que tenho material o suficiente pra compor mais um capítulo dessa série de artigos com o tema.

Fui introduzido ao conceito há pelo menos 4 anos antes da escrita desse texto, através de uma iniciativa interna da empresa na qual trabalho, como uma proposta de alavancar os níveis de alta disponibilidade. Quando fui confrontado por “qual seria o tema da minha pesquisa de mestrado”, tive a ideia de alavancar um conceito emergente de mercado academicamente, e Arquitetura Celular e seus arredores serviram como uma luva. Baita desafio. Precisei consolidar conceitos já firmados em mercado e academia, como replicação, bulkheads, isolamento de falhas e demais tecnologias cloud native, para sustentar o termo.

Esse texto se baseia em uma alternativa mais leve e menos formal de abordar o tema.

Definindo a Arquitetura Celular

O modelo de Arquitetura Celular é um modelo de arquitetura descentralizada onde as capacidades de uma organização são estruturadas em uma rede de células independentes e autocontidas, como uma evolução do que entendemos pelo Bulkhead Pattern. Uma distinção importante que vale reforçar é que a Arquitetura Celular não é simplesmente uma técnica de particionamento horizontal sofisticado; ela é um pattern avançado na forma como modelamos domínios de falha.

O conceito que conecta os bulkheads à Arquitetura Celular em sistemas complexos é a proposta de criar fronteiras de isolamento de falhas, garantindo que o impacto de um erro seja restrito a um número limitado de componentes, sem afetar o restante do ecossistema, com o adicional de componentes de replicação de dados entre células para conter ainda mais o escopo de uma eventual falha isolada.

Unidades Celulares

Uma célula não é apenas um agrupamento técnico de serviços. Ela representa uma segmentação arquitetural explícita. Essa segmentação deve existir em múltiplas dimensões simultaneamente, como segmentação de execução (capacidade computacional e capacidade de escalabilidade horizontal isolada e autocontida), segmentação de persistência, isolando databases independentes, segmentação de observabilidade, isolando métricas, logs e traces segmentados por contextos celulares, segmentação de deploy, possuindo pipelines complexos de deployment para atualizar células sem impacto direto ao seu público, e segmentação de falha, onde temos blast radius mensuráveis e segmentados.

O compartilhamento de componentes globais como filas, tópicos, caches e databases compartilhados invalida esse isolamento. Caso exista a necessidade, por exemplo, tópicos de comando e resposta por domínio e API Gateways centralizados, eles devem ser intermediados por outros componentes celulares de borda.

Dimensão estrutural de uma célula

Uma célula é um compilado de um ou mais componentes (microsserviços, funções, databases, gateways, etc.) agrupados desde o design até a implementação e implantação. Estruturalmente, ela possui as características de isolamento e independência, onde cada célula, ou conjunto de células, é responsável por atender uma parcela determinada do público de forma autocontida, e toda comunicação externa deve ocorrer obrigatoriamente através de um gateway de borda ou proxy, que expõe APIs, eventos ou streams de dados.

Os componentes internos comunicam-se de forma contínua intra-celular, enquanto dependências externas são mediadas pelo gateway da célula. Os componentes internos da célula só podem conhecer e se comunicar com componentes da própria célula, nunca de outra. Cada célula possui um nome e um identificador de versão único, facilitando o gerenciamento de dependências no ecossistema distribuído e resiliente.

Isolamento de estado

Uma característica determinística da implementação da arquitetura celular é que as células não compartilham estado com outras células de forma primária, apenas por replicação passiva. Em termos de persistência, uma célula pode conter seus próprios clusters de bancos de dados relacionais, sistemas de arquivos locais ou repositórios de dados necessários para cumprir sua função de negócio.

Cada unidade é independente e lida com um subconjunto específico das requisições totais do sistema e pode ter unidades passivas que assumem a liderança dos dados replicados em caso de falha da célula principal. No mais, cada célula deve possuir seus próprios microserviços, seus próprios bancos de dados, camadas de cache, consumidores de filas e eventos e demais componentes, de forma que sejam autocontidas e independentes entre si.

Esse modelo permite inclusive estratégias diferenciadas por célula. Uma célula pode operar com parâmetros de tuning diferentes, versões distintas de runtime ou até estratégias experimentais de feature rollout sem impactar o restante do ecossistema. Podemos isolar clientes de teste, pilotos e públicos sintéticos para experimentação antes de propagar versões para as demais células produtivas.

Estratégias de roteamento e direcionamento para células

O princípio fundamental é que toda requisição deve ser roteada para uma célula específica com base em uma chave estável, como customerId, accountId ou tenantId. Esse roteamento pode ocorrer em múltiplas camadas: DNS, API Gateway, proxies de borda ou service mesh.

É de grande importância para a solução que o algoritmo de roteamento seja determinístico, garantindo que requisições relacionadas ao mesmo estado sempre atinjam a mesma célula ativa. Em cenários de failover, o roteador deve ser capaz de redirecionar para a célula passiva correspondente sem que o cliente perceba a transição. Se um cliente hoje está na célula X, amanhã ele deve continuar na célula X, independentemente de picos de tráfego. Mudanças no algoritmo de hashing ou no número de células devem ser cuidadosamente orquestradas, pois podem causar remapeamento massivo (rehash storm).

Edge Cells - Células de Borda

A camada de roteamento que intercepta as comunicações dos clientes e realiza o redirecionamento para a célula, ou grupo de células correto, é conhecida como “Edge Cells”, ou “Células de Borda”, uma camada de roteamento inteligente que deve ser capaz de realizar, da forma mais performática possível, a interceptação das solicitações, sejam elas vindas de qualquer protocolo conhecido, e redirecionar de maneira correta para a célula disponível responsável por atender a solicitação.

É preferível que esta camada seja o mais stateless possível, mas é possível que a mesma mantenha um estado cadastral em alguma camada de dados adicional. Aqui vamos além de um proxy básico como um Nginx, Envoy e Haproxy; é uma aplicação inteligente e agnóstica para uso celular que deve ser capaz de absorver alto tráfego e gerenciar o capacity global das camadas celulares de aplicação. Ela precisa ser extremamente resiliente e, paradoxalmente, altamente distribuída para não se tornar o novo ponto único de falha.

Células e segmentação de carga

A segmentação de carga na Arquitetura Celular é uma decisão estrutural de como os dados serão divididos e replicados entre as células. Já abordamos esse tema profundamente no capítulo de sharding e particionamento. Isso vai muito além de um particionamento horizontal de dispersar throughput entre vários estanques isolados de capacidade. Em arquiteturas tradicionais, o load balancer distribui requisições de maneira estatística através de vários algoritmos como round robin, least connection e afins, mas o estado permanece logicamente compartilhado.

Já em uma arquitetura celular, a segmentação é determinística e vinculada a uma chave de negócio estável, podendo ser tratada de forma cadastral e mapeamento intencional, ou distribuída estatisticamente através de algoritmos de hashing e hashing consistente. Isso significa que cada célula absorve um subconjunto fixo e determinístico da carga total, e essa distribuição não varia dinamicamente conforme a pressão momentânea do sistema; os mesmos clientes sempre serão atendidos pela mesma célula, ou conjunto de células.

Células Síncronas

No contexto síncrono, o roteamento ocorre no caminho crítico da requisição. HTTP, gRPC ou mesmo protocolos binários proprietários são direcionados para uma célula específica antes da execução do fluxo transacional.

Aqui presumimos um gateway de borda que recebe todas as requisições de domínio. Esse gateway tem a função de atuar como um proxy de encaminhamento inteligente, como um roteador que sabe identificar deterministicamente, através de chaves conhecidas como ids de clientes, tenants, usuários, e direcionar para a célula, ou conjunto de células correspondente. Esse mecanismo de roteamento e proxy pode operar baseado em DNS, Hashing Consistente, roteamento via Service Mesh ou de forma cadastral, consultando fontes externas para determinar onde o cliente será direcionado.

Em cenários síncronos, a latência da célula é diretamente percebida pelo usuário. Portanto, cada célula deve ser dimensionada como unidade autônoma de performance. CPU, memória, conexões de banco, thread pools e limites de rate limiting devem ser configurados por célula, não globalmente. Cada célula precisa ter sua capacity isolada e independente.

Células Assíncronas

Quando entramos no domínio assíncrono, a arquitetura celular assume ainda mais capacidade e estratégia de desacoplamento estrutural. Em cenários de arquitetura celular que são acionadas por eventos em tópicos ou mensagens em filas, cada célula consome apenas as mensagens e eventos pertencentes a seu contexto.

Podemos presumir um consumidor de borda que consome alguma fila ou tópico de domínio e republica as mensagens ou eventos para tópicos e filas segmentados da célula, atuando como um filtro roteador da mensagem em contexto para sua célula específica, que por sua vez só conhece seus próprios mecanismos de mensageria.

A consequência é a eliminação do acoplamento temporal entre células. Uma célula pode atrasar processamento, sofrer backpressure ou mesmo ficar indisponível sem bloquear o restante do sistema. Ao segmentar tópicos e filas por célula, eliminamos o risco de backpressure global. Uma célula pode acumular backlog sem afetar a taxa de processamento das demais.

Replicação Celular

No modelo celular, a replicação é direcionada para a criação de células passivas que atuam como espelhos de células ativas nos requisitos de dados. Cada célula é projetada como uma unidade autocontida, incluindo todos os componentes de execução e armazenamento necessários para sua operação independente; porém, podemos assumir conjuntos de células passivas que recebem os dados de células ativas, prioritariamente com consistência eventual e replicação assíncrona através de componentes adicionais, ou com consistência forte, criando um modelo transacional de “Two-Phase Commit”, garantindo que todas as células participantes da replicação celular irão confirmar a transação ou ela será inteiramente abortada.

O foco na replicação para células passivas garante que falhas críticas como bugs, erros de deploy ou as chamadas poison pill requests (requisições corrompidas que derrubam o serviço) sejam contidas dentro da fronteira da célula afetada, mas que o cliente seja redirecionado para uma célula passiva para a qual seus dados estejam sendo replicados de forma transparente. Como cada célula atende a apenas um subconjunto das requisições totais, assumindo um roteamento forte por chave de partição, a perda de uma célula principal não resulta em um apagão da experiência do cliente.

Isso muda completamente a forma como modelamos risco sistêmico. Em vez de perguntar: “Qual o impacto da falha de um shard?”, passamos a perguntar: “Qual a probabilidade de um cliente estar alocado exatamente no subconjunto de células que falhou simultaneamente?”.

Replicação Assíncrona entre Células

A replicação assíncrona entre células de uma arquitetura desse tipo é o modelo mais comum dentro de arquiteturas celulares, principalmente quando podemos abrir mão de uma consistência forte nos critérios de alta disponibilidade e tolerância a falhas. Nesse modelo, a célula ativa é a fonte primária de escrita, enquanto células passivas recebem atualizações de estado por meio de streams de eventos, logs de mudança ou filas assíncronas.

O custo desse modelo é a aceitação da consistência eventual. O objetivo dessa estratégia é a propagação dos dados entre as células ativas e passivas fora do que consideramos o “caminho crítico” transacional do cliente, permitindo que as operações da célula continuem atendendo com baixa latência, mesmo sob carga elevada e saturação da célula. Em uma falha súbita da célula ativa, a célula passiva pode assumir com um pequeno atraso de estado.

Replicação Consistente entre Células

A replicação consistente entre células surge quando o domínio de negócio não tolera divergência de estado, mesmo que temporária, em uma eventual mudança de responsabilidade entre uma célula ativa e passiva. Nesses cenários, a arquitetura celular precisa incorporar mecanismos de coordenação distribuída, como Two-Phase Commit (2PC) ou variações mais modernas de consenso, para garantir um estado transacional em todas as células do conjunto do contexto.

Esse modelo assume mais complexidade e riscos, onde múltiplas células participam de uma transação distribuída, garantindo que o estado só seja considerado confirmado quando todas as células envolvidas reconhecem a operação e, em caso de qualquer participante falhar, a transação inteira é abortada, preservando uma integridade global.

Embora conceitualmente elegante, esse modelo introduz acoplamento temporal entre células, aumenta a latência e reduz a capacidade de isolamento absoluto de falhas. Por isso, sua aplicação deve ser extremamente criteriosa, restrita a fluxos realmente críticos e evitando um volume que possa desencadear uma saturação em cascata em todas as células participantes do conjunto.

Replicação e Shuffle Sharding

A combinação de arquitetura celular com shuffle sharding representa uma das estratégias mais eficientes para reduzir impacto sistêmico em larga escala e aplicar a replicação cross-celular.

Em vez de associar cada cliente ou tenant a uma única célula fixa, o shuffle sharding mapeia cada entidade a um subconjunto estável de células, calculado por hashing consistente. Assim, um cliente interage apenas com um pequeno grupo de células, e não com o sistema inteiro, assumindo que seus dados estão replicados entre todas elas de forma consistente ou assíncrona.

Quando uma célula falha, apenas os clientes cujo conjunto inclui aquela célula são afetados. Os demais continuam operando normalmente. Isso reduz drasticamente o blast radius estatístico, mesmo em sistemas com milhares ou milhões de clientes. Quando aplicamos o shuffle sharding, os clientes afetados podem ser redirecionados para uma célula ao lado, para a qual seus dados foram replicados; dessa forma, só começamos a calcular o blast radius a partir da falha de duas ou mais células (dependendo da quantidade de replicação cross-celular dos dados), e reduzimos a porcentagem de impacto para a probabilidade de os clientes estarem em todo o conjunto de células indisponíveis.

Replicação e Blast Radius

A principal característica da arquitetura celular, quando combinada com replicação, é a previsibilidade do impacto de falhas. Como vimos no exemplo dos Bulkheads, se uma carga de trabalho é distribuída igualmente entre 10 shards e uma delas falha, 90% dos usuários ou recursos permanecem operacionais e inalterados. Quando confrontamos com a proposta da Arquitetura Celular com replicação, o número de bulkheads ou shards computacionais, se presumirmos uma segmentação uniforme de carga, impacta diretamente a porcentagem de indisponibilidade em caso da falha de uma parcela isolada dessa segmentação.

Do ponto de vista matemático, se temos N células e roteamento uniforme por hashing consistente, cada célula tende a absorver aproximadamente 1/N da carga total. Isso permite modelar blast radius como função direta da cardinalidade de células.

Bulkheads	Blast Radius	Disponibilidade
1	100%	0%
2	50%	50%
3	33%	66%
5	20%	80%
10	10%	90%
20	5%	95%
50	2%	98%
100	1%	99%

A literatura clássica de sistemas distribuídos mostra que a replicação é um mecanismo-chave para garantir disponibilidade e continuidade operacional, permitindo que o sistema mantenha o serviço mesmo diante de falhas de nós ou partições de rede.

Do ponto de vista conceitual, células podem ser compreendidas como domínios de falha isolados, alinhados ao padrão arquitetural de bulkheads, cujo objetivo é compartimentalizar o impacto de incidentes. Quando trabalhamos com a replicação celular e temos a capacidade de redirecionar nossos clientes para células passivas que contenham seus dados, conseguimos adicionar ainda mais camadas de disponibilidade na experiência do cliente. O impacto de uma partição indisponível deixa de ser a métrica estatística apropriada, pois um shard indisponível pode ser suprido por sua versão passiva. Nesse caso, em níveis de replicação, passamos a estimar o impacto a partir de um conjunto maior de células indisponíveis, trabalhando com a probabilidade de um cliente estar alocado no conjunto todo que falhou.

O cálculo se baseia em células em status de falha (f) dividido pelo número total de células (N), elevado ao número de réplicas virtuais (k) do Shuffle Sharding.

\begin{equation} P(\text{impacto}) \approx \left( \frac{f}{N} \right)^k \end{equation}

Em exemplo, presumindo que trabalhamos com 20 células, 2 réplicas em shuffle, onde o mesmo dado de um cliente é alocado em 2 células, em caso de downtime de 2 células aleatórias, conseguimos calcular a probabilidade de um mesmo cliente estar alocado justamente nessas 2 células. Nesse caso, 1% de probabilidade. Comparado ao exemplo dos bulkheads, onde para ter 1% de impacto determinístico, precisaríamos de 100 bulkheads ou shards computacionais para ter o mesmo resultado de 20 células com fator de replicação de 2.

\begin{equation} P(\text{impacto}) \approx \left( \frac{2}{20} \right)^2 \end{equation}

\begin{equation} P(\text{impacto}) = \text{1%} \end{equation}

Quando ajustamos o número de réplicas em shuffle, diminuímos ainda mais a probabilidade de impacto, pois para existir um downtime total de um cliente, precisaríamos presumir uma quantidade cada vez maior de células inativas.

Células Totais	Células Indisponíveis	Réplicas em Shuffle	Probabilidade de Impacto do Cliente
20	2	2	1%
20	3	3	0.33%
20	5	5	0.009%

Referências

BR AWS re:Invent 2022 - Camada Zero: A real-world architecture framework (PRT268)

A Crash Course on Cell-based Architecture

Mastering Cell-Based Architecture for Modern Enterprises

Cell-Based Architecture Reference

Cloud Native Middleware: Domain-Driven Design, Cell-Based Architecture, Service Mesh, and More

Reference Architecture for Agility, Version-0.9

What is a cell-based architecture?

Guidance for Cell-Based Architecture on AWS

Two-Phase Commit

Shuffle Sharding: Massive and Magical Fault Isolation

Bulkhead Pattern -> Cell based architecture

Blueprint - Rate Limit por Pods com Istio Service Mesh

Wed, 18 Feb 2026 00:00:00 +0000

Este blueprint tem objetivo de mostrar a forma de utilizar o EnvoyFilter para implementar um rate limit local, a nível de pod, para preservar o capacity a nível proativo e restritivo de cada unidade da aplicação.

A prova de conceito busca validar formas de estabalecer uma restrição estável e fixa do quanto “cada pod da aplicação pode receber sem degradar”. Uma vez que essa informação é conhecida, podemos implementar rate limit de forma granular para preservar a saturação progressiva de cada unidade computacional. Para isso, vamos utilizar o Istio Service Mesh e o Envoy Filter para configurar a estabilidade local do serviço.

Se um cliente concentrar toda a carga em apenas um Pod (por afinidade de conexão ou hash), ele estará limitado a 3 TPS. Isso significa que o sistema, mesmo escalado horizontalmente, ainda respeita limites individuais de cada pod em execução, e não globalmente.

Entendendo o Algoritmo de Token Bucket do Envoy Proxy

O algoritmo de Token Bucket implementado pelo Envoy é um mecanismo de controle de taxa de requisição baseado numa ideia de crédito acumulativo de acordo com o tamanho do bucket e sua taxa de reposição.

Diferente de abordagens puramente restritivas como fixed window counters, o token bucket permite absorver pequenos bursts controlados, mantendo previsibilidade sob carga sustentada.

No contexto do envoy.filters.http.local_ratelimit, cada sidecar mantém localmente um bucket com três parâmetros fundamentais:

max_tokens — capacidade máxima do bucket.
tokens_per_fill — quantidade de tokens adicionados a cada intervalo.
fill_interval — periodicidade de reposição.

# ...
value:
    stat_prefix: http_local_rate_limiter
    token_bucket:
    max_tokens: 3
    tokens_per_fill: 3
    fill_interval: 1s
# ...

Caso o max_tokens e o tokens_per_fill possuam valores iguais, passamos convergir para um algoritmo de Leaky Bucket, onde não acumulamos creditos no bucket e passamos a aceitar e recusar requisições sobre uma taxa estável e fixa, cenário cujo qual vamos abornar dessa prova de conceito.

Implementação via EnvoyFilter

A implementação via EnvoyFilter insere o filtro HTTP local_ratelimit diretamente no HTTP Connection Manager do listener inbound do sidecar. O uso de context: SIDECAR_INBOUND garante que o controle seja aplicado na entrada do Pod, protegendo o workload antes mesmo da requisição atingir o container da aplicação

Exemplo - 3 Transações por Segundo por Pod

O cenário de entrada busca estabelecer um limite local de 3 transações por segundo para cada POD em serviço na estratégia de leaky bucket, ou seja, não existe margem para absorver picos de crédito.

2 pods
max_tokens: 3
tokens_per_fill: 3
fill_interval: 1s

O throughput máximo agregado será aproximadamente:

3 TPS × 2 Pods = 6 TPS

Exemplo Completo

apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: shard-router-local-rate-limit
  namespace: istio-system
spec:
  workloadSelector:
    labels:
      app: shard-router
  configPatches:
    - applyTo: HTTP_FILTER
      match:
        context: SIDECAR_INBOUND
        listener:
          filterChain:
            filter:
              name: "envoy.filters.network.http_connection_manager"
      patch:
        operation: INSERT_BEFORE
        value:
          name: envoy.filters.http.local_ratelimit
          typed_config:
            "@type": type.googleapis.com/udpa.type.v1.TypedStruct
            type_url: type.googleapis.com/envoy.extensions.filters.http.local_ratelimit.v3.LocalRateLimit
            value:
              stat_prefix: http_local_rate_limiter
              token_bucket:
                max_tokens: 3
                tokens_per_fill: 3
                fill_interval: 1s
              filter_enabled:
                runtime_key: local_rate_limit_enabled
                default_value:
                  numerator: 100
                  denominator: HUNDRED
              filter_enforced:
                runtime_key: local_rate_limit_enforced
                default_value:
                  numerator: 100
                  denominator: HUNDRED
              response_headers_to_add:
                - append: false
                  header:
                    key: x-local-rate-limit
                    value: 'true'

Exemplo - 10 Transações por Segundo por Pod

O segundo cenário busca estabelecer um limite local de 10 transações por segundo também na estratégia de leaky bucket.

2 pods
max_tokens: 10
tokens_per_fill: 10
fill_interval: 1s

O throughput máximo agregado será aproximadamente:

10 TPS × 2 Pods = 20 TPS

Exemplo Completo

apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: shard-router-local-rate-limit
  namespace: istio-system
spec:
  workloadSelector:
    labels:
      app: shard-router
  configPatches:
    - applyTo: HTTP_FILTER
      match:
        context: SIDECAR_INBOUND
        listener:
          filterChain:
            filter:
              name: "envoy.filters.network.http_connection_manager"
      patch:
        operation: INSERT_BEFORE
        value:
          name: envoy.filters.http.local_ratelimit
          typed_config:
            "@type": type.googleapis.com/udpa.type.v1.TypedStruct
            type_url: type.googleapis.com/envoy.extensions.filters.http.local_ratelimit.v3.LocalRateLimit
            value:
              stat_prefix: http_local_rate_limiter
              token_bucket:
                max_tokens: 10
                tokens_per_fill: 10
                fill_interval: 1s
              filter_enabled:
                runtime_key: local_rate_limit_enabled
                default_value:
                  numerator: 100
                  denominator: HUNDRED
              filter_enforced:
                runtime_key: local_rate_limit_enforced
                default_value:
                  numerator: 100
                  denominator: HUNDRED
              response_headers_to_add:
                - append: false
                  header:
                    key: x-local-rate-limit
                    value: 'true'

System Design - Bulkhead Pattern

Thu, 05 Feb 2026 00:00:00 +0000

O termo “Bulkhead” foi amplamente discutido em vários capítulos desta série de artigos, e o objetivo deste é ilustrar as nuances focadas nesse pattern em sua totalidade. Quando discutimos bulkheads, abordamos uma ampla gama de implementações e possibilidades, desde as mais internas, em nível de runtimes, até amplas aplicações arquiteturais e segmentações de operações e clientes. O objetivo deste artigo é ilustrar as principais capacidades desse tipo de pattern, bem como os tipos de vantagens e desvantagens em discussão.

Definindo Bulkheads

O Bulkhead Pattern é um padrão arquitetural de contenção de falhas, mas cujo objetivo central não é evitar que falhas aconteçam, e sim garantir que uma eventual adversidade em uma parte do sistema não se propague e o comprometa por inteiro. Ele parte do pressuposto de que falhas são inevitáveis em sistemas distribuídos e, portanto, devem ser estruturalmente esperadas, limitadas e absorvidas em diversas dimensões.

A essência do Bulkhead não está em mecanismos de retry, timeout ou fallbacks, mas na separação explícita de domínios operacionais. Quando corretamente aplicado, o sistema deixa de ser um bloco homogêneo e passa a se comportar como um conjunto de compartimentos independentes, cada um com capacidade, escalabilidade, limites e impacto bem definidos.

Bulkheads e a Engenharia Naval

O termo Bulkhead tem sua origem na engenharia naval. Dentro dela, bulkheads são paredes estruturais internas que dividem o casco de um navio em compartimentos isolados, para que, se por ventura ocorrer um dano no casco e um compartimento for perfurado, apenas aquela seção se encha de água, preservando a flutuabilidade do restante da embarcação. O objetivo dessa estratégia não é impedir que o dano aconteça, mas impedir sua propagação e, por sua vez, o naufrágio completo da embarcação. Esse mesmo raciocínio se aplica a sistemas críticos de larga escala e então foi portado para a engenharia de software como um conceito a ser estudado e entendido.

Bulkheads e a Arquitetura de Software

O Bulkhead Pattern é um padrão de design de resiliência aplicado em microsserviços, cujo objetivo é isolar falhas e impedir que um problema em um componente derrube todo o sistema. Na arquitetura de software, um bulkhead representa uma separação explícita e delimitada de recursos e de destinos de execução de transações. A ideia é segregar pools de recursos específicos para evitar que a saturação ou falha de um componente afete outros domínios ou segmentações de clientes de todo o sistema, e representa uma separação explícita de recursos e destinos de execução.

Um erro conceitual recorrente é imaginar que bulkheads precisam existir em apenas uma camada do sistema. Na prática, sistemas resilientes aplicam o mesmo princípio de isolamento de forma consistente ao longo da stack. É comum observar separação no nível de aplicação, mas não no banco de dados ou no isolamento de infraestrutura, mantendo, por exemplo, compartilhamento de filas ou tópicos.

O Bulkhead pode ser aplicado em diferentes dimensões, como pools de threads, filas, tópicos, pools de conexão, bancos de dados, VMs, containers, clusters ou shards. Se dois fluxos compartilham os mesmos recursos, as mesmas conexões ou os mesmos databases, eles não possuem bulkheads, pois a falha de um fluxo inevitavelmente se propaga para os outros.

Quando aplicado de forma correta, o sistema deixa de ser visto como um bloco único e altamente acoplado e passa a se comportar como blocos e partições independentes, cada um com sua própria capacidade, limites, escalabilidade, funcionalidades e usuários bem definidos.

Implementações e Contenção de Falhas

Bulkheads podem ser implementados em diferentes níveis da arquitetura, mas todos compartilham o mesmo objetivo: impedir que a saturação de um recurso consuma a capacidade global do sistema. A implementação correta exige clareza sobre quais recursos são finitos e como eles devem ser particionados. Para direcionar a estratégia de forma correta, precisamos pontuar de forma objetiva quais recursos são finitos no sistema, quais são críticos e como eles devem ser segmentados e, assim, definir formas de identificar, redirecionar, redistribuir e monitorar o tráfego e as operações nesses compartimentos distintos.

Recursos Lógicos

Bulkheads lógicos atuam sobre recursos de execução e concorrência, como threads, filas, conexões e limites de requisição. São os mais comuns e, ao mesmo tempo, os mais frequentemente mal implementados.

Um exemplo é o uso de thread pools dedicados para diferentes tipos de operação. Sem bulkhead, uma operação lenta ou bloqueante pode consumir todas as threads disponíveis, gerando gargalos e filas internas, acarretando saturação e problemas de performance. Com pools dedicados, a falha fica confinada ao fluxo que a originou.

Outro exemplo são filas e tópicos independentes por domínio, evitando que um pico de mensagens em um fluxo impeça o processamento de eventos críticos em outro. Com pools e “gatilhos” sistêmicos segregados, cada tipo de operação possui um limite claro de concorrência. Quando esse limite é atingido, apenas aquele fluxo degrada, enquanto os demais continuam operando dentro de parâmetros aceitáveis. O mesmo raciocínio se aplica a filas e tópicos independentes por domínio ou clientes, evitando que picos de eventos não críticos atrasem ou bloqueiem fluxos essenciais, que são críticos para outro tipo de público ou domínio.

Bulkheads lógicos são frequentemente confundidos com simples aplicações de rate limiting ou com limites globais de concorrência. No entanto, a diferença fundamental está no escopo do impacto. Um limite global protege o sistema como um todo, mas não protege os fluxos críticos entre si. Já o bulkhead lógico cria fronteiras internas, onde cada fluxo opera dentro de sua própria capacidade alocada.

No dia a dia de um time de engenharia, isso se traduz em decisões como pools de threads separados para leitura e escrita, filas distintas para eventos críticos e não críticos, ou até mesmo executores dedicados para integrações externas sabidamente instáveis. Um serviço que consome múltiplas APIs de terceiros não deveria permitir que a lentidão de uma integração consuma os recursos responsáveis por operações internas além desse processo. Cada integração externa representa, por definição, uma superfície de risco distinta e, portanto, merece seu próprio compartimento lógico.

Recursos Físicos

Bulkheads físicos envolvem a separação concreta de infraestrutura, como servidores, nodes, instâncias, zonas de disponibilidade ou até regiões. Aqui, o isolamento passa a ser definitivamente estrutural. Por exemplo, alocar workloads críticos e não críticos nos mesmos nós de um cluster cria um shared fate implícito. A saturação de CPU ou memória por um workload pode derrubar todos os outros. Separar esses workloads em pools de nós distintos cria um bulkhead físico que protege o sistema como um todo. Esse tipo de isolamento é mais caro, mas fornece garantias mais fortes, especialmente em sistemas de alta criticidade.

No dia a dia, isso aparece de forma clara em clusters Kubernetes, ambientes de virtualização ou até mesmo em servidores bare metal. Um workload mal dimensionado, com vazamento de memória ou comportamento não linear sob carga pode pressionar o kernel, o scheduler ou o hypervisor, afetando todos os serviços alocados por tabela. Nesse ponto, nenhum thread pool ou fila dedicada é suficiente para conter a falha; é necessária uma segregação física dos recursos. O critério utilizado para isso pode e deve variar, como, por exemplo, tipos de clientes, segmentos, prioridade, criticidade, hashing consistente, identificadores etc.

Bulkheads físicos surgem como resposta a esse tipo de risco. Separar workloads críticos em pools de nós dedicados, usar clusters distintos para domínios com SLOs incompatíveis ou até isolar componentes por região são decisões que aumentam o custo, mas reduzem drasticamente o blast radius.

Distribuição de Bulkheads e Blast Radius

A forma como shards são definidos, roteados e balanceados determina, de maneira explícita, o tamanho do blast radius, o comportamento sob sobrecarga e a previsibilidade da degradação. Em arquiteturas avançadas, sharding deixa de ser um detalhe de armazenamento ou roteamento e passa a ser um mecanismo primário de isolamento operacional.

Cada shard representa, na prática, um bulkhead completo ou parcial. Ele possui capacidade própria, limites próprios e uma curva de degradação própria. A distribuição correta desses shards permite transformar falhas sistêmicas em falhas estatisticamente localizadas. Um pico extremo deixa de ser um evento binário de “o sistema caiu” e passa a ser um evento probabilístico: “X% do sistema foi impactado”.

Bulkheads	Blast Radius	Disponibilidade	Impacto
1	100%	0%	Total
2	50%	50%	Muito alto
3	33%	66%	Alto
5	20%	80%	Moderado
10	10%	90%	Moderado
20	5%	95%	Baixo
50	2%	98%	Muito baixo
100	1%	99%	Mínimo

Quanto maior o número de shards, menor o blast radius, mas maior a complexidade operacional. O ponto central não é apenas quantos shards existem, mas como o tráfego é distribuído entre eles. Distribuições mal balanceadas, chaves de particionamento enviesadas ou algoritmos de roteamento instáveis podem concentrar carga excessiva em poucos shards, anulando completamente o efeito do bulkhead.

Bulkheads e Shardings

Sharding é uma das formas mais poderosas e perigosas de implementar bulkheads. Quando bem aplicado, oferece isolamento estrutural; quando mal projetado, cria acoplamentos invisíveis que só se manifestam sob estresse e acabam não impedindo a propagação de falhas de um recurso isolado. Aqui, é necessário segregar todos os recursos físicos que podem compor o bulkhead, como balanceadores de carga, aplicações, bancos de dados, tópicos, filas e afins, e criar réplicas literais dedicadas apenas para aquele bulkhead, de forma que os fluxos iniciados em uma segmentação do bulkhead permaneçam nele até o fim da execução e, assim, não ofereçam risco de performance e disponibilidade por conta da saturação de uso daquela partição específica do sistema. Outros bulkheads devem estar aptos a executar as mesmas funções, porém com capacidade isolada para outros tipos de públicos e operações.

Eles são especialmente relevantes para lidar com comportamentos não lineares de sistemas sob carga crescente. Em regimes próximos à saturação, pequenas variações de tráfego podem provocar aumentos desproporcionais de latência, consumo de memória, lock contention ou pressão sobre o scheduler. Sem bulkheads, esse comportamento não linear tende a se espalhar por todo o sistema, criando um efeito dominó em que fluxos originalmente saudáveis passam a degradar por compartilharem os mesmos recursos finitos. Tratados como complemento às estratégias de sharding, tendem a elevar os níveis de performance e disponibilidade.

Bulkheads de Sharding Funcional

No sharding funcional, o sistema ou domínio de negócio é dividido por funcionalidades e padrões de uso. Cada shard atende a um conjunto específico de funcionalidades, com recursos próprios e limites bem definidos.
Por exemplo, separar processamento de pagamentos, consultas e relatórios em shards distintos evita que um pico analítico degrade operações críticas de transação. Aqui, o bulkhead é alinhado ao valor de negócio.

É razoavelmente comum segregar bulkheads específicos para operações transacionais e just-in-time e uma separação dedicada para processamento de lotes e batches. Inserir uma quantidade gigante de processos em repouso para concorrer com fluxos que possuem SLOs e contratos de tempo de resposta e disponibilidade transacionais pode acabar gerando saturação e ofendendo os indicadores. Desse modo, é possível ter infraestrutura dedicada, dentro do possível, para direcionar solicitações em batch ou sincronizações agendadas de outros domínios e parceiros, e outra segregada para as operações convencionais do sistema.

Outra estratégia é ter infraestrutura dedicada para diferentes prioridades de processamento do mesmo tipo de transação, dedicando capacidade exclusiva para transações prioritárias, normais e de baixa prioridade, de forma que, em caso de um spike ou burst de solicitações normais ou de baixa prioridade que cheguem ao sistema, não comprometam as solicitações enviadas para o bulkhead de alta prioridade.

Bulkheads de Sharding Operacional

No sharding operacional, a divisão ocorre por volume ou características de carga, não por função. Exemplos comuns incluem sharding por identificadores de cliente, região ou faixa de tráfego.
Esse modelo é eficaz para limitar o blast radius de picos localizados, mas exige cuidado com operações globais, que podem atravessar múltiplos shards e reintroduzir acoplamento. É comum que shards sejam bem isolados no início, mas gradualmente passem a compartilhar dependências globais, como serviços de configuração, catálogos ou bancos de dados auxiliares. Esses pontos se tornam canais ocultos de acoplamento.

Arquiteturas de Bulkheads

Nesta seção vamos ilustrar algumas das possibilidades de segregação estrutural de bulkheads dentro da arquitetura de software, onde serão apresentadas estratégias para dedicar e isolar capacidade para diferentes tipos de contextos comuns presentes no dia a dia. Muitos deles já foram vistos e citados, mas aqui serão reabordados com uma recapitulação estruturada das estratégias.

Bulkheads por Priorização

Criar bulkheads de capacidade por priorização parte do princípio de que nem todas as transações possuem o mesmo valor sistêmico em termos de importância. A ideia é garantir capacidade reservada para fluxos com diferentes prioridades, para evitar, por exemplo, que filas FIFO, pools compartilhados ou aplicações generalistas colapsem por bursts ou picos de acesso, fazendo com que requisições críticas concorram e se atrasem por conta de requisições menos relevantes.

Na prática, esse padrão aparece em sistemas financeiros, plataformas de pedidos ou sistemas de autenticação, onde fluxos de escrita transacional, confirmação de pagamento ou autenticação de sessão não podem ser impactados por cargas secundárias, como reprocessamentos, sincronizações ou integrações assíncronas que exijam muito da capacidade computacional.

Bulkheads por Criticidade

Bulkheads por criticidade vão além da prioridade momentânea e refletem o impacto sistêmico da falha de um fluxo. Enquanto priorização responde à pergunta “o que deve ser atendido primeiro?”, criticidade responde “o que não pode falhar”. Podemos replicar e alocar capacidade computacional para clientes que precisam estar inerentes a infraestruturas auditadas por regulamentações específicas, como, por exemplo, PCI Compliance, certificações ISO ou HIPAA, fazendo com que seja possível atender critérios específicos de isolamento e auditabilidade para cada tipo específico de necessidade.

Bulkheads por Tipo de Uso

Bulkheads por tipo de uso surgem quando o mesmo sistema atende padrões de carga radicalmente diferentes, e permitem separar usos por fluxos interativos, síncronos e sensíveis à latência de fluxos batch, assíncronos ou orientados a maior throughput. A separação existe porque esses perfis possuem curvas de comportamento opostas, mas precisam da mesma funcionalidade. Operações interativas exigem baixa latência, previsibilidade e rejeição rápida sob sobrecarga. Operações batch toleram latência elevada, mas consomem recursos de forma agressiva e prolongada. Quando ambos compartilham os mesmos recursos, o comportamento batch tende a dominar, pressionando CPU, memória, IO e filas internas, degradando silenciosamente os fluxos interativos.

O bulkhead por tipo de uso não tenta “otimizar” o batch ou operações de leitura intensiva, mas impedir que eles concorram estruturalmente com operações sensíveis. Isso costuma aparecer como filas, workers, clusters ou até pipelines de deploy distintos para cada tipo de uso. O batch pode atrasar, acumular ou até ser pausado, sem que isso altere o SLO das operações online.

Bulkheads por Segmento

Os bulkheads por segmento tratam explicitamente do problema de heterogeneidade de comportamento entre grupos de usuários, clientes ou regiões. Clientes enterprise, parceiros estratégicos ou segmentos regulados não podem compartilhar o mesmo destino operacional que usuários experimentais, testes A/B ou integrações instáveis.

Sistemas que atendem diversos públicos podem segmentar capacidade operacional para lidar com divergências de criticidade e expectativas, como, por exemplo, públicos de pessoa física, pessoas jurídicas, pessoas publicamente expostas e clientes prioritários. Dessa forma, é possível criar estratégias para que, em caso de contenção de falhas, nem todos os segmentos sejam afetados simultaneamente.

Isso também cria um espaço saudável para negociação de SLOs, precificação diferenciada e evolução independente de capacidade.

Bulkheads por Hashing Consistente

Bulkheads por hashing consistente são a forma mais estatística de aplicar isolamento operacional quando o objetivo é distribuir carga e isolar parcelas de falhas de maneira mais determinística. A ideia é, por meio de um algoritmo de roteamento, proxy ou roteador, utilizar uma chave estável, como tenantId, customerId, accountId ou deviceId, e utilizá-la para enviar as solicitações sempre para o mesmo conjunto de recursos.

Em um balanceamento clássico (round-robin, least-connections), um pico localizado de um único cliente “vaza” para toda a frota, porque o balanceador distribui indiscriminadamente. Com hashing consistente, o pico do cliente fica concentrado no(s) shard(s) aos quais ele foi mapeado.

Bulkheads por Tenants

Isolar tenants vai muito além de separar dados dos mesmos em tabelas ou instâncias de dados diferentes. Trata-se de garantir que o comportamento de consumo, erros ou picos de um tenant não alterem o perfil operacional dos demais. Em plataformas SaaS, isso frequentemente significa criar limites explícitos de capacidade por tenant, combinando bulkheads lógicos e físicos conforme o nível de criticidade e monetização.

Podemos ter réplicas inteiras de toda a infraestrutura dedicadas para cada um dos tenants, que são roteados por meio de regras de balanceamento, ingress ou DNS, isolando totalmente a operação dos mesmos para evitar noisy neighbor.

No mundo real, é comum observar plataformas que isolam dados, mas compartilham integralmente threads, filas e infraestrutura. O resultado é que um único cliente com comportamento anômalo pode comprometer toda a experiência da plataforma. Bulkheads por tenant transformam esse risco em um problema localizado, em que a degradação é previsível, mensurável e, principalmente, negociável do ponto de vista de negócio.

Noisy Neighbor e Bulkheads Tenants

O problema do “noisy neighbor”, ou vizinho barulhento, surge quando múltiplos tenants compartilham os mesmos recursos físicos e lógicos, e o comportamento de um impacta negativamente os demais. Sem bulkheads, basta um tenant com desvio de comportamento e saturação acima do previsto para degradar toda a plataforma.
Esse problema é especialmente crítico em plataformas SaaS e ambientes multi-tenant de alta escala.

Referências

Bulkhead Pattern — Distributed Design Pattern

Bulkhead Pattern in Microservices

Bulkhead pattern

Building a fault tolerant architecture with a Bulkhead Pattern on AWS App Mesh

Bulkhead Pattern

Failsafe - Bulkhead Go

System Design - Capacity Planning e a Teoria das Filas

Mon, 12 Jan 2026 00:00:00 +0000

Capacity planning não é sobre prever o futuro com precisão absoluta. É sobre entender os limites estruturais do sistema antes que eles se tornem incidentes. A maioria dos problemas de capacidade não surge de crescimento repentino, mas da incapacidade de interpretar o comportamento do sistema sob carga real. Métricas isoladas, como CPU, memória ou TPS médio, raramente contam a história completa. O que realmente importa é como esses sinais se relacionam, como a concorrência interna se acumula e onde os gargalos se formam quando a carga deixa de ser uniforme.

Passei os últimos 3 meses do ano de 2025 procurando modelos matemáticos para me guiar nos assuntos de capacity planning e performance para minha caixa de ferramentas. Aqui, guardo um compilado dos conceitos e fórmulas mais relevantes que encontrei. Rascunhei este capítulo logo em seguida a uma das etapas mais intensas do meu mestrado, e seu resultado final foi uma linguagem muito mais densa e teórica do que os anteriores, mas gostei muito do resultado.

Este texto não é um guia para dimensionar servidores. É uma abordagem sistemática para modelar carga, interpretar saturação e planejar crescimento de forma estruturada. A teoria das filas, a Lei de Little e a curva do joelho não são apenas abstrações acadêmicas, são ferramentas práticas para responder perguntas como “quanto meu sistema aguenta de forma sustentável?” e “onde ele quebra antes de eu perceber?”. O objetivo é transformar capacity planning de uma reação a incidentes em uma prática de engenharia preventiva e bem fundamentada.

Teoria das Filas

A teoria das filas é um dos fundamentos mais importantes e mal compreendidos em capacity planning. Em termos simples, a teoria estuda como sistemas se comportam quando múltiplas demandas competem por recursos finitos. Em engenharia de software, podemos utilizar como base comportamentos comuns, como requisições síncronas aguardando processamento para responder a um cliente, mensagens acumuladas em filas, múltiplos itens sendo processados em memória, conexões disputando pools limitados em bancos de dados ou operações de I/O esperando acesso a um recurso compartilhado.

De forma conceitual, toda fila pode ser entendida a partir de três dimensões: como as demandas chegam ao sistema, como elas são processadas e em que ordem são atendidas. O objetivo é transformar arquiteturas complexas em modelos matematicamente analisáveis, principalmente em arquiteturas distribuídas, onde taxas de uso estáveis e tempos de resposta previsíveis raramente se sustentam de forma consistente.

As “filas” não existem apenas onde há estruturas literais de enfileiramento assíncrono, como brokers de mensagens e eventos. Embora a teoria das filas seja vista apenas como uma abstração acadêmica na maior parte dos casos, ela nos fornece formas de compreender gargalos, throughput real, tempo de resposta e latências em cascata decorrentes de cenários como saturação de pools de threads, conexões de banco de dados, locks em recursos compartilhados e mecanismos de retry, não apenas de forma isolada, mas sobretudo em arquiteturas distribuídas, onde cada hop, cada requisição, cada buffer e cada microserviço se comporta como uma fila independente, com sua própria taxa de chegada, taxa de processamento, saturação e congestionamento.

Da forma mais simples, uma fila é um mecanismo onde solicitações chegam (λ) e são processadas (μ), e o sistema oscila continuamente entre estados de ociosidade, equilíbrio e saturação dentro desses dois parâmetros. Quando a taxa de chegada (λ) se aproxima ou ultrapassa o limite da taxa de processamento (μ), isso gera um gargalo físico, onde tempos de resposta aumentam e o throughput degrada por haver uma taxa de envio maior do que a taxa de vazão. É por esse tipo de detalhe técnico que um microsserviço saudável em p95 pode degradar de forma significativa em p99 sob picos inesperados, mesmo com CPU e outros recursos aparentemente estáveis. No geral, o problema não é a falta de capacidade física, mas sim a variabilidade temporal, bursts e o custo de espera entre chamadas e processos.

Isso explica por que o autoscaling normalmente não resolve todos os problemas de capacidade, uma vez que ele reage apenas a aumentos expressivos de uso ou saturação de recursos para adicionar ou remover réplicas de um serviço. O autoscaling, de forma superficial, aumenta a taxa de processamento (μ) momentaneamente, permitindo que a taxa de vazão cresça, mas ainda funciona com base em gatilhos temporais, deixando o sistema sensível a bursts e picos de uso. Em outras palavras, um sistema não sofre porque recebe “muitas requisições”, mas porque recebe requisições de forma imprevisível ou não uniforme.

A teoria das filas propõe o uso de métricas de variabilidade, como o coeficiente de variação ou o desvio padrão, em vez de medidas como percentis, mínimos, máximos e médias na taxa de processamento. Analisamos, então, a variação da taxa de chegada (λ) e da taxa de processamento (μ). Essa visão explica por que sistemas com a mesma capacidade de recursos podem apresentar comportamentos completamente distintos sob carga real. Dois serviços com a mesma taxa média de atendimento podem exibir curvas de latência radicalmente diferentes se um deles processar requisições com desvio padrão elevado.

Estratégias já discutidas anteriormente, como sharding, bulkheads, caching, escalabilidade vertical e horizontal, desacoplamento por meio de filas e eventos, aumento do número de consumidores, bem como estratégias de concorrência e paralelismo, nos ajudam a lidar com a estabilidade dos sistemas quando a taxa de chegada supera a taxa de processamento.

A Lei de Little na Teoria das Filas

A Lei de Little, ou Little’s Law, é um princípio matemático simples integrado à Teoria das Filas, apresentado por John D. C. Little na década de 1960, que nos fornece insights valiosos para entender o comportamento de qualquer sistema sob carga. A lei não foi inicialmente formulada para conceitos computacionais complexos; ela pode ser utilizada para analisar a pressão de qualquer tipo de sistema sob a ótica da média de três variáveis, sendo elas o número médio de itens em processamento no sistema (L), a taxa média de chegada (λ) e o tempo médio de processamento e permanência desses itens (W) no sistema. Essa relação é expressa pela equação:

\begin{equation} L = \lambda \times W \end{equation}

Esse cálculo, por mais que seja simples, é válido para interpretar qualquer sistema estável, pois independe de estatísticas complexas e de valores exatos da taxa de processamento e permanência (W) e da taxa de chegada de itens ao sistema (λ), desde que suas médias sejam bem definidas.

Em sistemas distribuídos, a Lei de Little nos ajuda a interpretar a capacidade de forma granular, a nível de cada componente, dependência ou microserviço, ou de forma mais ampla, analisando um fluxo completo em cenários onde estimar as capacidades exatas de todos os componentes pode ser muito complexo ou inviável.

Em termos práticos, ela se resume a uma interpretação adicional de capacidade sobre throughput e latência. Para uma taxa de chegada fixa (λ), qualquer aumento no tempo médio de resposta (W) implica, de forma imediata, um aumento proporcional no número de processos simultâneos (L) no sistema.

Considere um sistema assíncrono que recebe uma taxa média de 1.500 mensagens por segundo, com tempo médio de processamento por mensagem de 50ms. Aplicando a Little’s Law, podemos encontrar o número de processos concorrentes dentro do mesmo segundo:

\begin{equation} L = 1.500 \times 0.05 \end{equation} \begin{equation} L = 75 \end{equation}

Neste cenário, o sistema mantém, em média, 75 mensagens simultaneamente em processamento ou espera. Esse valor representa a concorrência média interna do sistema e pode ser utilizado como base para dimensionamento de consumidores, threads de processamento, partições de filas ou limites de paralelismo, servindo como fator base para antecipar degradações ou otimizações de forma proativa, sem depender de saturação. Lembrando que, com base interpretativa do modelo, quanto menor o valor de L, melhor.

Pequenos aumentos no tempo médio de processamento impactam diretamente o número de mensagens acumuladas, aumentando o risco de atraso e crescimento não controlado da fila, por exemplo, em um aumento do tempo de processamento para 85ms:

\begin{equation} L = 1.500 \times 0.085 \end{equation}

\begin{equation} L = 127 \end{equation}

Ao elevar o tempo médio de processamento, mesmo para um aumento aparentemente pequeno e plausível em cenários reais, causado por variação de payload, latência de dependências externas, I/O ou demais contenções externas, o número médio de mensagens em voo salta para 127 de concorrência interna, um aumento absoluto de 52 mensagen

Lei de Little e o “Ponto Saudável”

A Lei de Little nos fornece um critério de avaliação para encontrar um “ponto saudável” de operação de um sistema, no qual entendemos que, com o crescimento da carga (λ), não teremos aumento descontrolado da concorrência interna (L).

Para tornar isso palpável, podemos adotar um L(Alvo) para o sistema, como um Service Level de engenharia, que representa um número máximo desejável de itens em concorrência interna, sendo esse compatível com os limites físicos e operacionais da solução, nos levando à busca por otimizações constantes para reduzir o tempo de processamento (W).

Considere uma API REST que possui um L(Alvo) de 150. O sistema recebe 500 requisições por segundo, com um tempo médio de resposta de 300ms. Pela Lei de Little:

\begin{equation} L = 500 \times 0.3 \end{equation}

\begin{equation} L = 150 \end{equation}

Esse cenário caracteriza o contrato do “Ponto Saudável”, onde o sistema opera dentro do limite planejado de concorrência interna e mantém uma certa previsibilidade e margem para absorver variações. À medida que a carga cresce no sistema para 1000 requisições por segundo, o L vai para 300, ultrapassando o L(Alvo) e podendo levar o sistema para uma região de saturação e risco.

Uma progressão saudável nos leva à pesquisa interna para lidar com uma redução proporcional do tempo de processamento W. Aqui aplicamos diversas técnicas de otimização para diminuir o tempo de processamento dos requests. Podemos descobrir o tempo-alvo para otimização (W) dividindo nosso L(Alvo) pela taxa de requisições recebidas (λ) atual e multiplicando, de forma categórica, para chegar à mesma unidade de tempo que estamos utilizando — no caso do exemplo, milissegundos:

\begin{equation} W = \frac{\text{L(Alvo)}}{\lambda} \times 1000 \end{equation}

Convertendo para o exemplo da nossa API:

\begin{equation} W = \frac{150}{1000} \times 1000 \end{equation}

\begin{equation} W = 150ms \end{equation}

Nesse cenário, podemos entender que, para que nosso sistema volte a operar com o L(Alvo) de 150, precisamos diminuir nosso tempo de processamento (W) de 300ms para 150ms. Nesse novo formato otimizado, o sistema processa 50% mais requisições mantendo a mesma concorrência média interna. O objetivo é que o crescimento seja absorvido estruturalmente, sem acúmulo adicional de filas ou pressão excessiva sobre recursos.

Knee Curve (Curva do Joelho)

A Knee Curve, ou Curva do Joelho, é um conceito que demonstra a relação entre a utilização de um sistema e o seu ponto de degradação de capacidade. Em um teste de carga, representa o ponto onde o tempo de resposta muda drasticamente em relação à tendência anterior.

Em termos normais, a latência cresce de forma linear conforme a quantidade de requisições que um sistema está lidando aumenta. A Curva do Joelho revela o ponto a partir do qual o sistema deixa de se comportar de forma previsível e passa a apresentar degradação acelerada.

Enquanto a utilização está antes da formação do “joelho”, o sistema tem capacidade de operar de forma saudável e segura e absorver pequenas variações de carga. Operar próximo ou além da curva aumenta significativamente o enfileiramento interno de recursos, o número de retries e a saturação dos componentes.

Podemos aplicar o modelo a outras métricas além de requests propriamente ditos. É possível utilizar recursos físicos como CPU e memória para entender a partir de que ponto de uso o sistema começa a degradar em throughput e latência, e, a partir disso, estimar suas capacidades e definir automações preventivas de auto scaling de forma mais assertiva.

Em paralelo à Teoria das Filas, à medida que a utilização cresce e se aproxima da capacidade máxima ou ultrapassa o “Ponto Saudável” definido pela Lei de Little, as filas internas começam a se formar e o tempo de espera passa a ser dominante em relação a todo o tempo de processamento definido. A partir desse ponto, a latência cresce de forma não linear, frequentemente exponencial, mesmo quando o aumento de utilização adicional é pequeno ou aparentemente irrelevante.

Em testes de performance, encontrar a curva do joelho do sistema permite identificar dois pontos importantes: o “Ponto Saudável” e o “Ponto Máximo de Utilização”. O Ponto Saudável, normalmente, é uma zona anterior à Curva do Joelho onde existe o maior equilíbrio operacional entre eficiência e previsibilidade. Dentro desse intervalo, entendemos que o throughput cresce de forma saudável e os tempos de resposta permanecem conhecidos e controlados.

Já o Ponto Máximo de Utilização corresponde ao limite teórico em que o sistema ainda processa requisições, porém à custa de latências elevadas, alta imprevisibilidade e risco significativo de indisponibilidade e falhas na experiência do usuário. O ideal é que ambas as zonas se estabeleçam antes da curva do joelho definitiva: uma para operação normal e outra para definição explícita do limite máximo de risco aceitável.

Margens Seguras de Saturação

Quando olhamos para recursos físicos sob a ótica de capacity planning, como, por exemplo, a utilização de CPU, não devemos interpretá-los com o objetivo de maximização como prioridade, mas sim como recursos finitos com margens de proximidade instáveis.

Quando comparamos, por exemplo, CPU e memória com outros recursos como largura de banda, armazenamento e IOPs, suas saturações não se manifestam de maneira linear e não representam recursos definitivamente livres para serem alocados como um simples “espaço disponível”. Esse fenômeno pode ser interpretado por meio da Teoria das Filas. Pequenos aumentos de utilização próximos de um “Ponto Saudável” de uso de CPU provocam crescimento de filas de forma desproporcional, sem que esses limites estejam necessariamente próximos de 100% de utilização.

Os “Pontos Saudáveis” de CPU e memória são zonas de utilização onde o sistema consegue absorver variações de carga, como spikes, bursts e jitters, sem exaurir a taxa de processamento (μ) ou aumentar o tempo de processamento (W), evitando a geração de filas e gargalos. O ponto central é que não é necessário atingir 100% de CPU para que o sistema crie e inflacione filas internas. Próximo de 80–85% de utilização, incrementos marginais de carga já produzem aumentos desproporcionais em latência e concorrência.

Modelagem de Carga

A modelagem de carga é um dos principais requisitos para se estimar o capacity planning de um sistema. Dentro de ambientes modernos, possuímos diversas ferramentas de monitoramento e observabilidade que coletam sinais de logs, métricas e traces emitidos pelas aplicações e seus componentes para gerar diversas dimensões de visualizações e alertas. Quando vamos estimar a capacidade de um sistema, precisamos analisar algumas delas de forma unificada e correlacionada.

Transações por segundo, requests concorrentes e o payload médio formam, em conjunto, uma representação mais fiel do comportamento real do sistema do que qualquer uma dessas métricas analisada de forma independente pode gerar. Juntas, essas três métricas formam a base mais sólida para uma modelagem de carga realista.

As Transações por Segundo descrevem o ritmo de solicitações, a concorrência descreve a pressão acumulada no sistema perante a chegada dessas solicitações, e o tamanho do payload descreve o peso individual de cada transação, a nível de networking, storage, custo de serialização e consumo de memória.

Transações por Segundo

As Transações por Segundo representam a taxa de chegada de requisições ao sistema e constituem o ponto inicial de qualquer estimativa. Nenhuma métrica é mais importante do que a quantidade de interações que um sistema recebe, ou irá receber.

Mesmo dentro do mesmo segundo, um sistema ainda pode apresentar insights valiosos sobre bursts. Dois sistemas podem operar com o mesmo TPS médio e apresentar comportamentos totalmente diferentes se a distribuição temporal dessas transações variar. Um workload com 1000 TPS distribuídos de forma homogênea ao longo do segundo impõe uma pressão completamente distinta de outro com a mesma média, porém concentrado em bursts de 5–10 ms, e conhecer esse nível de granularidade pode nos ajudar a estimar, com muito mais precisão, a capacidade necessária para suprir as demandas de forma inteligente.

Processos Concorrentes

Os requests concorrentes representam uma dimensão interna do sistema que reflete sua capacidade de processamento. Diferentemente das Transações por Segundo, que descrevem a taxa de chegada de solicitações ao sistema, os Processos Concorrentes descrevem a quantidade de trabalho simultâneo que o sistema sustenta.

Em sistemas síncronos, como servidores gRPC ou APIs REST, isso se manifesta como threads ocupadas, conexões abertas, entre outros recursos concorrentes. Em sistemas assíncronos, pode ser interpretado como mensagens em voo, partições ocupadas, consumidores ativos e taxa de processamento de eventos e mensagens em brokers.

Podemos ilustrar esse comportamento em APIs que apresentam latências aceitáveis em p95, mas mantêm concorrência interna elevada devido a pequenas degradações em dependências externas. Nesses casos, a capacidade aparente parece suficiente, enquanto o sistema já opera próximo a limites estruturais invisíveis. Ter consciência de como estimar e medir a concorrência interna é fundamental para evitar esbarrar nas “curvas do joelho” do sistema.

Tamanho de Payload

Estimar o tamanho do payload, sejam eles mensagens ou requests HTTP, é uma dimensão que é rotineiramente ignorada durante a estimativa de capacidade. Em sistemas com requisições mais homogêneas, ou seja, microserviços que possuem poucos endpoints ou contratos bem definidos de mensagens e eventos, é possível prever o tamanho desses payloads com certa precisão e estimar de forma mais confiável a pressão de tráfego de I/O que o sistema irá lidar. Porém, em sistemas que possuem múltiplas funcionalidades distribuídas em diversas filas e endpoints, o payload médio pode não representar uma dimensão fiel à realidade do sistema. O risco do erro da estimativa não está na média dessa variável, mas sim na dispersão em torno dessa média.

Payloads maiores tendem a ampliar o tempo de processamento, o consumo de memória, a pressão em garbage collection, o uso de buffers de rede e a latência de serialização. Um sistema que processa majoritariamente payloads pequenos, mas ocasionalmente recebe payloads muito maiores, pode apresentar comportamento estável na média e, ainda assim, sofrer degradações abruptas sob cenários perfeitamente válidos do ponto de vista funcional. Essa variabilidade cria caudas longas no tempo de resposta e amplifica o efeito de filas internas, mesmo sem alterações perceptíveis na TPS.

Idealmente, precisamos modelar sistemas e contratos que não sofram grande variação de tamanho. Quando isso não for possível, é necessário estimar cada uma das funcionalidades de forma isolada e se concentrar em encontrar alguma estatística que represente de maneira mais fiel o sistema diante de suas particularidades.

Cálculos de Estimativa de Carga

Podemos estimar matematicamente nossa modelagem de carga com uma série de equações simples que podem ser aplicadas a dimensões já conhecidas do sistema ou fornecidas por times de produto. A seguir, iremos abordar como expandir ainda mais a aplicação dessas equações em cenários mais específicos.

Estimativa de Transações por Segundo

Quando falamos sobre Performance, Capacidade e Escalabilidade, já ressaltamos o quanto o throughput é uma métrica extremamente valiosa e importante para entender todo tipo de comportamento do sistema. Essa métrica é a primeira a precisar ser levantada porque conecta diretamente o comportamento do usuário à pressão exercida sobre a arquitetura.

Embora simples, o TPS deve ser interpretado como um valor estatístico médio, mínimo e máximo, e não como um fluxo contínuo e uniforme. Em sistemas reais, a taxa de chegada oscila ao longo do tempo, sofre efeitos de sincronização, burstiness e correlação entre usuários ou clientes. Levantar o desvio padrão do TPS também pode fornecer insights valiosos sobre a variação do mesmo ao decorrer de certos períodos.

\begin{equation} \text{TPS} = \frac{\text{Unidades de Trabalho Processadas no Período}}{\text{Tempo em Segundos do Período}} \end{equation}

Na prática, esse valor costuma ser extraído de métricas sazonais de séries históricas, projeções de crescimento ou metas de negócio, e posteriormente ajustado para picos, sazonalidade e eventos especiais que podem acontecer em certos períodos do mês ou do ano, como promoções, ações de marketing, Black Friday, Natal, entre outros.

TPS Sistêmico

O TPS Sistêmico representa a capacidade efetiva de vazão de todo o sistema, considerando não apenas a aplicação principal, mas todas as suas dependências críticas. Em arquiteturas distribuídas, o throughput observado externamente é sempre limitado pelo menor gargalo ativo no caminho de processamento.

\begin{equation} \text{TPS Sistêmico} = \min(\text{TPS App}, \text{TPS Database}, \text{TPS Cache}, \text{TPS etc.}) \end{equation}

Não importa o quão escalável seja a camada de aplicação se o banco de dados, o cache, o broker de mensagens ou uma API externa impõem limites mais restritivos. Além disso, o gargalo dominante pode mudar dinamicamente conforme o perfil de carga, o tamanho de payload ou o tipo de operação.

Estimativa de Tamanho de Payload

A estimativa de tamanho de payload busca quantificar o volume médio de dados trafegados por requisição, considerando tanto o corpo da mensagem quanto o overhead de protocolos de transporte, como HTTP, TLS, mTLS, entre outros.

\begin{equation} \text{Payload_bytes} = (\text{Body_bytes} + \text{Headers_bytes}) \end{equation}

Entretanto, em sistemas reais, é necessário considerar camadas adicionais de overhead, como encoding, compressão, criptografia e framing de protocolo, que podem tanto ampliar quanto reduzir o tamanho efetivamente trafegado.

\begin{equation} \text{Payload_bytes} = (\text{Body_bytes} + \text{Headers_bytes}) \times \text{Overhead} \end{equation}

Mais importante do que o valor médio absoluto é a variabilidade do payload, pois payloads grandes tendem a amplificar latência, consumo de memória e tempo de processamento, criando caudas longas que afetam a estabilidade do sistema, mesmo quando a média parece controlada.

Estimativa de Bytes de Uma Transação

Enquanto o payload representa uma única mensagem, a estimativa de bytes por transação considera o custo completo de uma interação, incluindo request e response. Essa visão é mais adequada para análises de capacidade fim a fim e para estimativas de custo e banda sob carga real.

\begin{equation} \text{Payload_médio(bytes)} = \text{Request_payload} + \text{Response_payload} \end{equation}

Essa métrica se torna especialmente relevante em APIs verbosas, fluxos com respostas ricas em dados ou sistemas onde o volume de resposta cresce com o contexto da operação. Ignorar o payload de resposta é um erro comum que pode fazer muita diferença para entender divergências entre estimativas e o tráfego real.

Estimativa de Banda pelo Payload e Transações por Segundo

A estimativa de banda conecta diretamente o throughput lógico (TPS) com o consumo físico de rede. A partir do payload médio por transação, é possível estimar o volume de dados trafegados por segundo e, consequentemente, dimensionar links, limites de ingress e custos de transferência.

\begin{equation} \text{Banda_bytes/s} = \text{TPS} \times \text{Payload_médio(bytes)} \end{equation}

Esse cálculo fornece uma aproximação inicial, que deve ser refinada com fatores como retries, retransmissões, fan-out interno e replicação de tráfego entre zonas ou regiões.

Perfis de Tráfego

Os Perfis de Tráfego permitem compreender como a carga do sistema se distribui ao longo do tempo, revelando padrões de uso, assimetrias e variações que não aparecem em métricas agregadas. Ao analisar comportamentos diários, semanais e sazonais, é possível antecipar picos previsíveis, identificar janelas de ociosidade e planejar capacidade de forma proativa, alinhando desempenho, custo e previsibilidade, vamos explorar conceitualmente cada um deles.

Perfil Diário

O Perfil Diário busca estudar o comportamento de uso do sistema ao decorrer de um dia corrido, um período fechado de 24 horas. Normalmente, está associado aos hábitos e à rotina dos usuários e aos agendamentos das integrações sistêmicas. Aqui temos análises mais granulares, com agregações de poucos minutos, como 1, 2, 5 e 10 minutos, para análises de tendência. Podemos, aqui, analisar diversas estatísticas, como média, p95, p99, tempo máximo e mínimo da agregação dos requests.

Em sistemas com finalidade operacional voltados a usuários finais, podemos entender em que momento do dia eles começam a operar dentro do sistema, normalmente tendo sua maior pressão de tráfego dentro das janelas de expediente, aliviando nos horários de almoço e ficando com pouco ou nenhum tráfego durante a noite e a madrugada. Em sistemas de delivery de comida, podemos presumir os maiores picos de uso minutos ou horas antes dos horários de almoço e jantar; em sistemas de carona, próximos do início e do fim do expediente; e, em sistemas B2B ou internos, os picos tendem a se alinhar a rotinas operacionais, fechamentos de lote ou execuções agendadas.

Do ponto de vista de capacity planning, o perfil diário é crítico porque define a duração dos períodos de alta e baixa utilização. Podemos utilizar esse tipo de estudo para entender os momentos do dia em que nosso tráfego irá aumentar de forma rotineira, ajustando preventivamente nossa capacidade, ou quando o sistema ficará subutilizado.

Perfil Semanal

O Perfil Semanal busca entender padrões de carga que se repetem durante os dias da semana, em um período de 7 dias, para encontrar padrões e desvios de uso, erros e latência distribuídos ao longo da semana. Para isso, utilizamos agregações de tempo maiores, como 1, 2, 3 e 5 horas, ainda aplicando estatísticas de média e percentis de forma comparativa para entender desvios e comportamentos do sistema.

Um sistema pode operar confortavelmente abaixo do ponto saudável durante boa parte da semana e, ainda assim, entrar em regiões de saturação previsível em dias específicos. Diferente do perfil diário, que tende a ser mais suave e previsível, o perfil semanal pode introduzir assimetrias abruptas, como segundas-feiras sistematicamente mais carregadas ou sextas-feiras com picos concentrados em horários específicos, uso mais suavizado durante o restante dos dias úteis e tráfego baixo durante os finais de semana.

Esse perfil é útil para entender desvios de uso do sistema e nos ajuda a projetar capacidade com base em períodos repetitivos dentro de uma semana, nos proporcionando formas de realizar warm-ups preventivos ou descomissionamento de contêineres ou servidores em períodos de ociosidade conhecida.

Perfil Sazonal

O Perfil Sazonal descreve variações de carga em escalas mais longas, como semanas, meses ou anos, e está normalmente associado a ciclos de negócio, eventos externos ou mudanças de comportamento dos usuários. Esse tipo de dimensão nos ajuda a projetar diversas estratégias valiosas de capacity planning. Aqui, a agregação pode ser feita em períodos maiores, como dias ou semanas.

Essa estratégia nos permite estudar o crescimento gradativo do sistema e como ele se comporta em períodos específicos de fatias de tempo maiores. Exemplos comuns incluem períodos promocionais, datas comemorativas, ciclos fiscais, eventos regulatórios ou mesmo fatores externos, como clima e calendário escolar. Podemos atingir níveis de escalabilidade adequados analisando apenas períodos mensais ou semanais, mas, ainda assim, sofrer falhas de capacidade em determinados períodos não estacionários do ano que não seguem o padrão de um “mês comum” ou “semana comum”, como, por exemplo, e-commerces durante promoções de Black Friday, onde uma semana específica de novembro excede todos os padrões observados no restante do ano.

A combinação dos perfis diários para análises granulares, semanais para identificação de tendências e sazonais em nível de mês e ano nos permite elevar significativamente nossa capacidade de projetar e estimar a capacidade dos sistemas ao longo de longos períodos de forma profissional e estruturada.

Projeção de Crescimento

A projeção de crescimento é um exercício de capacity planning no qual a análise deixa de ser estática e reativa e passa a adotar estratégias de antecipação. Diferente do tópico anterior, em que as estimativas buscavam entender o sistema e compreender seus comportamentos e tendências, a projeção busca responder a uma pergunta um pouco mais difícil: como a carga do meu sistema será daqui a 3, 6 ou 12 meses?

Responder a esse tipo de pergunta exige uma análise temporal extensa do passado para entender o crescimento natural e também uma parceria com os times de negócio para compreender as expectativas e perspectivas de mercado da empresa para os produtos. A missão da engenharia é suportar as expectativas dos produtos de forma sustentável e realista, portanto, as expectativas sobre o futuro do sistema devem ser de conhecimento comum entre tecnologia e negócios.

Crescimento Linear

O crescimento linear assume que métricas como TPS, volume de dados ou usuários ativos aumentam de forma proporcional ao tempo. O número de usuários, licenças, transações ou compras cresce seguindo uma tendência semelhante todos os meses ou semanas. Pequenas variações dessa taxa, para mais ou para menos, não descaracterizam esse comportamento como linear nesse tipo de cenário.

Podemos encontrar esse padrão em estágios iniciais de um produto ou em sistemas muito bem estabelecidos — cenários opostos, mas que compartilham uma tendência de crescimento previsível e estável. Nesse tipo de análise, entendemos, por inferência, que dobrar a quantidade de transações ou usuários de um sistema implica diretamente em dobrar sua capacidade.

Crescimento Não Linear

Em sistemas mais variáveis, o tráfego e a capacidade raramente crescem de forma linear, podendo apresentar comportamentos não previsíveis ao longo do tempo, alternando períodos lineares, exponenciais ou irregulares.

O crescimento não linear tende a invalidar análises de comportamento prévias. Esses cenários podem ocorrer devido a mudanças de comportamento dos usuários ou à introdução de novas funcionalidades, onde pequenas variações no número de usuários ou eventos podem gerar aumentos desproporcionais em TPS, latência ou concorrência interna. Esse tipo de variação também pode ocorrer em função de testes de estratégias de marketing e negócios, que provocam comportamentos imprevisíveis de novos usuários e cargas no sistema.

Crescimentos não lineares e não planejados podem ser extremamente perigosos para sistemas que operam próximos da sua taxa máxima de processamento conhecida.

Crescimento Mediante Novas Features e Eventos de Negócio

Uma dimensão extremamente significativa que nos permite atuar em conjunto com os times de negócio é a projeção de crescimento mediante mudanças, novas features e eventos planejados. O perfil de tráfego de um sistema pode se alterar de forma brusca com a introdução de novas funcionalidades, migrações de usuários ou campanhas de marketing de conversão, entre outros fatores. Ter esses eventos alinhados com os times responsáveis nos dá a oportunidade de trabalhar de forma planejada e preventiva para suportar essa nova entrada de carga.

Uma mudança ou evento de negócio voltado a atrair mais usuários para o sistema ou aumentar sua taxa de uso pode deslocar os limites de processamento, aproximando o sistema de sua “curva do joelho” de performance e capacidade com as funcionalidades já existentes. Além disso, a adição de uma nova feature pode multiplicar o número de chamadas internas por requisição, aumentar significativamente o payload médio ou introduzir dependências adicionais no fluxo sistêmico. Realizar testes de carga contemplando as características das novas funcionalidades é fundamental para reavaliar a capacidade necessária para atendê-las de forma adequada.

Nem toda mudança ou feature exige um novo planejamento de capacidade em nível de detalhe máximo, mas aquelas que têm o objetivo explícito de alterar o comportamento do sistema como um todo precisam, sim, ser consideradas para garantir maior segurança. Levantar estimativas e expectativas com todos os envolvidos nessas mudanças é essencial para planejamentos mais assertivos.

Capacidade End to End (E2E)

Avaliar a capacidade End to End de um fluxo, sistema ou transação nos ajuda a tomar responsabilidade sobre o encadeamento total entre os serviços que os compõe. Avaliar todas as dependências e integrações, como a soma de todas as capacidades individuais, revela onde o fluxo se limita, onde os gargalos emergem e quais sistemas podem falhar sobre carga real. Precisamos avaliar tanto o Throughput Individual de cada sistema para ter uma margem de avaliação e o sistêmico, onde vamos avaliar como todos os “steps” se comportam em cadeia.

Throughput individual

O throughput individual representa a capacidade máxima sustentável de um componente isolado dentro do sistema, avaliada fora do contexto completo do fluxo fim a fim. Ele descreve quanto trabalho um serviço, banco de dados, fila ou consumidor consegue processar por unidade de tempo sob condições controladas, considerando seus próprios limites de CPU, memória, I/O, concorrência e configuração interna.

Essa dimensão pode ser avaliada em dois cenários. No primeiro, considera-se o contexto de um microserviço e suas dependências diretas, como caches, filas e bancos de dados, onde a capacidade individual é avaliada dentro de um domínio de serviço. No segundo, a análise ocorre em cada microcomponente de forma isolada. O primeiro cenário serve para avaliar uma fragmentação específica de negócio, como “quanto esse sistema de emissão de boletos consegue processar”, enquanto o segundo responde perguntas como “quanto esse banco de dados suporta de I/O” e métricas derivadas. Ambos fornecem insights valiosos sobre capacidade de produção.

Throughput sistêmico

O throughput sistêmico corresponde à capacidade máxima de um sistema ou funcionalidade, contemplando todas as suas dependências. O objetivo é ser agnóstico à capacidade individual de cada componente, levando em consideração apenas o fluxo completo, da entrada até a resposta final. Essa estratégia serve para avaliar a capacidade total da solução e identificar oportunidades de melhoria relacionadas a filas e gargalos.

Em termos práticos, o throughput sistêmico busca identificar o ponto de desequilíbrio entre a taxa de chegada (λ) e a taxa de processamento (μ) em cada hop do fluxo, determinando qual componente exerce maior pressão contrária ao processamento fim a fim. Mesmo que serviços isolados operem com folga, o sistema como um todo pode apresentar throughput limitado quando a variabilidade de throughput e latência se acumula ao longo da comunicação end to end.

Do ponto de vista de capacity planning, medir throughput sistêmico implica observar o comportamento do sistema sob carga contínua, e não apenas picos instantâneos. Um sistema pode atingir um TPS elevado por curtos períodos e, ainda assim, não ser capaz de sustentar essa vazão ao longo do tempo, caracterizando uma capacidade apenas nominal, e não operacional.

Dependência do Gargalo

Como discutido no capítulo sobre performance, capacidade e escalabilidade, gargalos são “pontos no sistema onde o desempenho ou a capacidade são limitados devido a um componente específico que não consegue lidar eficientemente com a carga atual”. Se, para completar uma transação, é necessária a resposta de três microserviços — onde um deles consegue processar de forma saudável 400 transações por segundo, outro 600 e outro 1000 — o sistema como um todo fica limitado à menor taxa de processamento, ou seja, 400 transações por segundo. Exceder essa taxa tende a provocar filas sistêmicas e pressão crescente sobre processos, threads e dependências associadas ao ponto de gargalo, impactando todo o fluxo da aplicação.

\begin{equation} \text{Gargalo} = \min(s_1, s_2, s_3, \ldots) \end{equation}

O gargalo atual do sistema é representado pelo componente ou processo com a menor taxa de processamento (μ) em todo o fluxo. Identificar essa dependência é fundamental para direcionar melhorias de forma priorizada e estratégica. Como visto anteriormente, os gargalos também se movem com o tempo: uma otimização local pode simplesmente deslocar o gargalo para outra parte subsequente do sistema.

Planejamento de Capacidade

O objetivo desta seção é fornecer um roteiro aplicável de planejamento de capacidade, levando em conta a base teórica compilada ao longo deste capítulo. A partir daqui, apresento uma “pseudo-estrutura” de um movimento de capacity planning para que seja criado um mapa mental adaptável a diversos cenários.

Delimitar o Fluxo, Funcionalidades e Componentes

O primeiro passo a ser seguido é definir qual fluxo sistêmico está sendo avaliado. Testar “o sistema” como um todo pode levar a modelagens genéricas que não refletem com precisão a realidade esperada. Portanto, identifique as funcionalidades, os contratos, os métodos de entrada, os serviços envolvidos, os dados manipulados, as respostas geradas e para onde elas são enviadas.

Nessa fase de levantamento, precisamos listar todos os microserviços, seus bancos de dados, filas e tópicos, bem como identificar quais fluxos são síncronos, quais são assíncronos e como todos eles se comunicam entre si. Esse passo estabelece o escopo do throughput sistêmico, evitando análises locais desconectadas da experiência real do usuário.

Levantar as Estimativas de Carga

Com o fluxo definido, o próximo passo é construir a carga base, utilizando exatamente as métricas discutidas anteriormente, como o TPS médio, os picos, os perfis diários e semanais, além das datas ou períodos sazonais que indicam mudanças de comportamento e o quanto essas variações podem ocorrer.

Devemos estimar os payloads, seus tamanhos e o volume de banda que irão trafegar durante os perfis levantados. Aqui também surge a oportunidade, caso ainda não esteja claro, de alinhar com os times de produto e de negócio quais são as variáveis esperadas de tempo de resposta e disponibilidade. Tornar esses indicadores explícitos é um grande facilitador para avaliar se o capacity planning está efetivamente adequado, ou se estamos subprovisionando ou exagerando em recursos ociosos.

Neste ponto, o objetivo não é precisão absoluta, mas ordem de grandeza. O modelo inicial serve para responder à pergunta: “em que condições meu sistema opera hoje?”, evitando projeções desconexas ou irreais.

Identificação do Throughput Individual dos Componentes e Serviços

Antes de projetar crescimento, é necessário entender os limites individuais de cada componente relevante do fluxo, identificando quais deles podem exercer pressão contrária, agravar gargalos ou gerar “curvas do joelho” de forma prematura, e, principalmente, em que condições isso acontece.

Aqui lidamos com variáveis como o TPS máximo sustentável do serviço, os limites de concorrência — threads, conexões e consumers disponíveis — e a capacidade efetiva de cada uma de suas dependências, como bancos de dados, caches, brokers e APIs externas. Dependências externas podem ser mockadas em ambientes controlados para que não comprometam testes de limite operacional do serviço.

Derivação do Throughput Sistêmico

A partir dos throughputs individuais, deriva-se o throughput sistêmico, aplicando explicitamente a lógica do menor gargalo. Aqui respondemos perguntas como: qual componente limita a vazão hoje? O gargalo é rígido ou pode lidar com escalabilidade horizontal dentro de uma determinada janela de tempo? O throughput, o tempo de resposta e a taxa de erros variam de acordo com o tempo e com as oscilações de tráfego dentro dos perfis de carga identificados?

Essa etapa é uma das mais importantes do processo, pois a capacidade real emerge do encadeamento entre os serviços, e não da análise isolada de componentes.

Levantamento da Projeção de Crescimento

Com a capacidade atual compreendida, o planejamento passa a incorporar projeções, evitando o erro clássico de assumir um único crescimento linear. Nesse momento, é fundamental incluir os times de negócio e, quando necessário, níveis executivos, para entender as expectativas futuras do sistema.

O objetivo aqui não é prever o futuro com precisão, mas entender até que ponto o sistema atual consegue suportar os objetivos da empresa e identificar oportunidades de melhoria para o horizonte planejado, evitando que a evolução ocorra de forma reativa, já com a experiência do cliente degradada.

Avaliar o Custo e as Margens Operacionais

Neste ponto, o planejamento incorpora explicitamente custo e risco. A pergunta deixa de ser “quanto o sistema aguenta” e passa a ser “quanto ele aguenta com previsibilidade e custo aceitável para o negócio”. Trabalhamos com dimensões como o impacto de overprovisioning versus underprovisioning, quais regiões do “Ponto Saudável” são aceitáveis do ponto de vista orçamentário e como isso se relaciona com a zona de pré-joelho de throughput e latência do sistema.

Aqui, a capacidade passa a ser tratada como orçamento, e não apenas como um limite técnico.

Definição dos Limites Operacionais

O resultado do capacity planning não deve ser um único número de “quanto aguenta”, mas sim um conjunto de limites operacionais bem definidos, como o TPS sustentável, o L(Alvo), a latência máxima aceitável (em termos de média e percentis) e a taxa de erro máxima tolerável. Essas definições precisam ser amplamente conhecidas entre os stakeholders do produto, pois também ajudam a identificar pontos futuros onde uma reavaliação arquitetural será necessária, alinhando expectativas de orçamento e planejamento estratégico.

Testes de Carga e Estresse

O último passo é validar, na prática, se o sistema atende aos requisitos estabelecidos e se possui as parametrizações adequadas para escalar de forma dinâmica ou estática. Aqui, devemos executar testes de carga média (Average Load), estresse, spikes conhecidos e testes de breakpoint para identificar quando o sistema ultrapassa o L(Alvo) e onde ele efetivamente entra em colapso.

Esses testes podem ser realizados de forma pontual, mas o ideal é que sejam executados por períodos prolongados, aproximando-se de cenários reais de operação. É fundamental coletar evidências e documentar a capacidade real, e, quando gargalos ou oportunidades de melhoria forem identificados, direcioná-los ao backlog para tratamento e priorização.

Referências

Improving the performance of complex software is difficult, but understanding some fundamental principles can make it easier.

Teoria das Filas

Elementos das Teorias das Filas

Lei de Little (Little’s Law): A Ciência por Trás de Fazer Menos e Entregar Mais

Little’s law

Knee of a curve

The “Knee” in Performance Testing: Where Throughput Meets the Wall

A Capacity Planning Process for Performance Assurance of Component-Based Distributed Systems

Capacity Planner - Google

System Design - Event Sourcing

Fri, 21 Nov 2025 00:00:00 +0000

Dando sequência à exploração de patterns arquiteturais da série de System Design, hoje vamos colocar um marco de complexidade estrutural falando de Event Sourcing e dos conceitos e componentes que viabilizam a implementação do mesmo. O objetivo deste capítulo será oferecer uma revisão honesta e conceitual sobre a adoção desse modelo, e também suas complexidades sistêmicas, que são altas.

Ao longo do conteúdo, são discutidos os principais conceitos que compõem esse modelo, como Event Store, Event Bus, Projections, Read Models, Snapshotting e Rehydration, e como eles se relacionam para formar um ecossistema transacional e historicamente reconstruível.

Além dos fundamentos conceituais, o texto aborda estratégias práticas para lidar com consistência eventual, versionamento, idempotência e controle de concorrência, temas essenciais para o design de sistemas distribuídos de alta confiabilidade e larga escala.

Definindo Event Sourcing

Event Sourcing é um padrão arquitetural que busca registrar todos os eventos que alteram o estado de uma entidade em uma base de dados de forma histórica. Esse padrão é usado para “contar a história” de uma transação ou entidade ao longo de todo o seu ciclo de vida.

Em sistemas em que uma entidade muda com frequência, como, por exemplo, os estados de um pagamento, os estados de um usuário ou operador do sistema, uma compra ou as fases de fabricação de um produto, o Event Sourcing visa registrar cada alteração de forma imutável.

O objetivo não é armazenar apenas o estado atual, mas todas as alterações ao longo do tempo de forma cronológica, como um log de eventos que podem ser auditados e recompostos. Isso é útil em sistemas event-driven, que emitem eventos constantemente para outros sistemas e que, eventualmente, precisam recompor os estados de forma distribuída.

Persistência Tradicional e Event Sourcing

À medida que a evolução arquitetural de sistemas distribuídos ocorre e desenvolve integrações e dependências mais complexas, a forma tradicional de persistir o “estado atual” de um registro dentro do sistema tende a se tornar limitada devido a critérios de resiliência e recuperação de falhas.

Em modelos tradicionais, o paradigma central é o “State Mutation”, onde o estado atual é sempre substituído a cada operação que ocorre. A proposta é responder como uma entidade do sistema “está agora”, mas não “como ela chegou até aqui”.

Como visto, o estado de cada entidade é mutável por padrão, ou seja, cada operação de INSERT, UPDATE e DELETE substitui as informações anteriores, apagando o histórico. Por exemplo, em um sistema de pagamentos, podemos receber uma série de eventos de domínio que representam ações realizadas diretamente sobre a entidade.

Evento	Ação	Status
PagamentoCriado(valor=100)	Insert	status=criado
PagamentoConfirmado	Update	status=confirmado
PagamentoEstornado	Update	status=estornado

O modelo de Event Sourcing propõe uma inversão conceitual, onde, em vez de armazenar o estado atual de entidades e registros após uma série de operações de INSERT, UPDATE e DELETE, o sistema acumula uma sequência de eventos imutáveis e armazena todos eles para derivar o estado atual.

Cada operação representa uma ação imutável que indica que “algo aconteceu” e está permanentemente registrada, fazendo com que o estado represente, de fato, uma sequência ordenada e temporal de eventos, e não apenas sua atualização mais recente.

Todas as operações em um sistema baseado em Event Sourcing são naturalmente inserções de novos dados sobre o estado da entidade, sendo necessário recuperar o último estado sempre que ele precisar ser consultado. Isso exige mais das operações de leitura em casos de alto volume — um trade-off conhecido, em que é necessário empregar otimizações avançadas.

Esse modelo de persistência, quando construído de forma consciente e responsável, permite criar sistemas auditáveis, reproduzíveis e naturalmente reativos, mas exige um nível elevado de maturidade de engenharia para evitar pontos de gargalo e custos excessivos.

Arquitetura Event-Sourcing

Agregados

Dentro de uma arquitetura de Event Sourcing, o agregado é a unidade lógica e transacional que agrupa uma entidade e todas as regras de negócio necessárias para garantir sua consistência interna. Ele representa o objeto no qual eventos são aplicados, validados, ordenados e evoluídos, assegurando que o estado resultante seja sempre derivado de uma sequência determinística de fatos temporais.

Agregados são a estrutura de dados que permite um contexto de consistência, responsável por decidir quais eventos podem ocorrer, em que ordem e sob quais condições, preservando as modificações das entidades dentro do domínio. Dentro do agregado, as mutações de estado são convertidas em eventos imutáveis, que posteriormente serão armazenados no Event Store e publicados no Event Bus, sendo a principal fonte de dados de uma arquitetura de Event Sourcing.

Event Store

O Event Store é o banco de dados central de uma arquitetura baseada em Event Sourcing. Um banco de dados de Event Store deve ser tratado como um ledger imutável, responsável por armazenar o log de todos os eventos que registram mudanças de estado das entidades do sistema, respeitando uma ordem temporal e absoluta.

A estrutura de dados de um Event Store, em vez de atualizar o estado atual, deve anexar um novo evento ao final do fluxo (stream) associado a uma determinada entidade ou agregado. Cada stream representa a linha do tempo de uma transação.

Um Event Store não armazena o estado de fato, apenas a história completa dos fatos. Por isso, o ponto crítico da construção dessas soluções está em garantir ordenação e atomicidade, para que seja possível reconstruir a entidade reaplicando os eventos em sequência.

Ao reaplicar os três eventos da transação 432, o estado é reconstituído totalmente e de forma fiel, resultando no estado pago, com dois produtos adicionados ao cliente a.

Esse modelo é análogo ao append-only log, usado por sistemas como Kafka ou bancos contábeis — os dados nunca são substituídos, apenas acumulados. Por isso, é comparado a um ledger distribuído: um registro permanente, auditável e verificável ao longo do tempo de tudo o que aconteceu dentro de um domínio.

Modelar o Event Store de forma agnóstica em relação ao tipo de operação efetuada é um requisito obrigatório. Isso envolve utilizar campos livres ou blobs para armazenar dados e metadados do evento com fins de replicação e reprocessamento, além de empregar índices para otimização de consultas transacionais e recuperação de estados históricos.

Não é necessário utilizar bancos relacionais ou não relacionais para projetar Event Stores, embora isso seja o mais indicado. É possível utilizar opções como EventStoreDB e Apache Kafka para tais finalidades, considerando seus trade-offs de flexibilidade na gestão dos dados.

Event-Bus e Publishers

Dentro — e fora — de uma arquitetura de Event Sourcing, o Event Bus é o componente responsável por permitir que os eventos gerados dentro de um domínio sejam publicados e propagados para outros domínios, sistemas e subsistemas interessados nos acontecimentos e nas mudanças de estado de suas entidades.
Seu objetivo é carregar esses eventos de forma desacoplada até os consumidores do sistema.
O Event Store é o registro de verdade — a golden source dos eventos —, enquanto o Event Bus é o meio de projeção das consequências desses eventos.

Os publishers são componentes de um sistema baseado em Event Sourcing responsáveis por publicar os eventos confirmados no Event Store em tópicos, filas ou barramentos.
Esse comportamento de publicação deve ser atômico, e os eventos só podem ser emitidos no Event Bus quando a gravação e outras operações forem bem-sucedidas.
O Event Bus pode ser implementado sobre tecnologias como Kafka, RabbitMQ, SQS, NATS ou Pulsar, dependendo do SLA e das garantias necessárias.

Embora não sejam componentes obrigatórios em uma arquitetura de Event Sourcing, o Event Bus e o Event Store são grandes facilitadores em implementações de microserviços orientados a eventos.
De qualquer forma, um Event Bus deve preservar a ordenação dos eventos por stream ou aggregate e garantir que o evento seja entregue pelo menos uma vez, com deduplicação para evitar repetições não intencionais e idempotência no nível dos consumidores para permitir reprocessamentos seguros.

Um sistema baseado em Event Sourcing pode possuir múltiplos barramentos de service bus, responsáveis por registrar e transmitir eventos de domínio para consumidores específicos, com ações distintas em diferentes domínios.

Um Event Bus com características de ledger distribuído, responsável por registrar de forma histórica todas as ações efetuadas dentro de contas bancárias ou livros-caixa, pode emitir eventos como “Nova Conta Registrada” para domínios que precisam persistir previamente uma estrutura base de conta antes de começar a consumir o evento central, como, por exemplo, uma transação, um saldo (Balance) ou um extrato (Statement).

Assim que forem emitidos eventos dentro do Event Sourcing responsável por registrar as transações, essas mensagens de transações persistidas são transmitidas para outro barramento de Event Bus, encarregado de notificar os domínios de que esses eventos ocorreram, permitindo compor o saldo e registrar de forma histórica os eventos de extrato.

Dessa forma, conseguimos notificar e recompor entidades inteiras dentro de domínios que aplicam suas próprias características de Event Sourcing ou persistência transacional, mantendo arquiteturas orientadas a eventos de forma eventualmente consistente.

Projections e Modelos de Leitura

Os Event Stores em sistemas baseados em Event Sourcing são otimizados para grandes volumes de escrita, porém podem apresentar desafios de leitura e recuperação de dados. Os bancos de dados principais devem conter apenas os logs dos fatos.
Para criar consultas sistêmicas e alimentar APIs ou outros processos, precisamos construir modelos otimizados para leitura.

Eventos, por definição, são ações que ocorreram no passado.
Projections são componentes ou processos utilizados para interpretar esses fatos e transformá-los em algo utilizável sistemicamente, em termos de leitura.
Uma projection é a consolidação de vários eventos de um mesmo identificador ou entidade que, após interpretados, resultam em um modelo de leitura (Read Model) armazenado para consultas otimizadas.

Em outras palavras, as projections são processos que “ouvem” os eventos do Event Store e atualizam uma visão derivada em um formato otimizado para leitura, seja do próprio sistema ou de outros.
Esses modelos são conhecidos como Modelos de Leitura (Read Models) e podem, sim, ser construídos sob uma visão de State Mutation.

Projections são normalmente construídas com base no padrão CQRS (Command-Query Responsibility Segregation), no qual se porta, de forma síncrona ou assíncrona, um modelo otimizado para escrita para outro modelo otimizado para leitura.
Nos Read Models, podemos utilizar bancos de dados em memória para respostas rápidas, bancos orientados a documentos para buscas textuais ou ainda modelos relacionais e não relacionais para relatórios consolidados.

Read Models não são apenas caches de leitura — são representações materializadas e derivadas de fatos históricos ocorridos e registrados no Event Store.
Isso significa que eles devem evoluir junto com o domínio e com a semântica dos eventos, operando em tempo próximo do real.

Ao contrário do Event Sourcing, as projections são determinísticas em relação ao estado atual.
Os processos de replay dos eventos — em caso de reprocessamento temporal para recomposição de estados — devem refletir também nas projections, garantindo que elas representem o estado atual do sistema.

Em sistemas maiores, múltiplas projections coexistem, cada uma representando uma visão específica: analytics, relatórios, dashboards, filas de envio, catálogos etc.
Seguindo boas práticas de reprocessamento e elasticidade inerentes ao domínio principal, as Read Models distribuídas tornam-se efêmeras e descartáveis, podendo ser reconstituídas a qualquer momento.

Projections e Read Models Transacionais

Dentro de um modelo transacional, podemos agrupar pequenas projections dentro do mesmo banco de dados do Event Store de forma atômica.
Um Event Store não é otimizado para leitura — é otimizado para escrita intensiva.
Em processos que exigem alta carga de trabalho e grandes volumes de dados, uma quantidade maior de operações dentro de uma única transação do Event Store pode gerar gargalos e demandar escalabilidade vertical das aplicações e bancos de dados.

Nesse modelo, a prioridade é preservar atomicidade e consistência imediata.
Isso significa que, dentro de uma única transação, tanto o evento quanto a projeção derivada são persistidos de forma atômica.
O maior benefício desse modelo é a eliminação da latência entre escrita e leitura, permitindo consistência imediata em valores que não toleram divergência em nenhum estado.
Por outro lado, ele adiciona complexidade operacional ao Event Sourcing e aumenta a carga de operações sobre o Event Store, tornando-se um possível gargalo em cenários de alta volumetria.

Em contextos de grande volume, é comum aplicar o padrão “Transactional Outbox” como mecanismo mitigador.
Nesse padrão, o evento é escrito junto da projeção dentro da mesma transação, mas publicado posteriormente de forma assíncrona — garantindo atomicidade sem bloquear o throughput e criando uma ponte para o modelo semissíncrono.

Projections e Read Models Semissíncronos

O propósito inicial de um Event Sourcing é gerar uma fonte segura e confiável de dados transacionais, que possam ser reconstituídos e replicados.
No modelo transacional, como visto anteriormente, mesmo que algumas Read Models sejam construídas dentro do próprio Event Store de forma atômica, idealmente elas devem ser encaminhadas para aplicações responsáveis por tratar e otimizar esses dados para leitura, lidando com os dados transacionais apenas para atualização e reconstrução das projections.
Em outras palavras, é necessário reduzir qualquer outra operação que possa comprometer a capacidade dedicada à escrita e à confiabilidade.

Nesses casos, podemos aproveitar a afinidade transacional do Event Store para tratá-lo como uma “golden source atômica”, atualizando as Read Models de forma assíncrona e eventual.
Dessa forma, mantemos duas fontes do mesmo dado — uma voltada exclusivamente para persistência e confiabilidade, e outra otimizada para consulta, modelo ideal para grandes volumes de dados.

Operações de saldo precisam ser executadas de forma atômica e transacional para evitar inconsistências.
Devemos garantir exclusão mútua e lidar com diversas operações por meio de transações, assegurando que todos os lançamentos e movimentações sejam processados corretamente para se chegar ao saldo atual.
Essas operações podem ser executadas dentro de um Event Store.
Após cada transação, o novo saldo é calculado de forma atômica e publicado no Event Bus, onde pode ser consumido por um Read Model otimizado para consulta e exposição em cenários de alto volume de requisições.

Assim, o Event Store atua como a “fonte de verdade” e o Read Model como o “estado derivado seguro”.
Esse modelo deve ser adotado apenas quando é possível lidar com otimismo entre os níveis de consistência.

Projections e Read Models Assíncronos

Em sistemas que toleram consistência eventual, podemos encaminhar os dados registrados no Event Sourcing via Event Bus para a construção de Read Models diretamente nos domínios interessados, removendo assim qualquer complexidade adicional do Event Store.

Dessa forma, a capacidade do Event Store permanece dedicada exclusivamente a registrar, confirmar e repassar os logs temporais, garantindo uma sequencialidade atômica.
Todos os modelos de leitura são construídos e processados de forma totalmente desacoplada do Event Store, porém assumimos que há um aumento computacional significativo em cada processo de reconstrução, sendo necessário o envio completo dos logs para reconstituição.

Eliminamos a complexidade e a demanda computacional do motor de eventos, transferindo-as para cada aplicação e domínio responsáveis por tratar os dados de forma agnóstica.

Reconstituição de Estados e Rehydration

A reconstituição de estado de um agregado dentro do Event Sourcing, popularmente conhecida como Rehydration, é o processo pelo qual utilizamos os logs sequenciais registrados no Event Store para reconstruir o estado de entidades e operações dentro e fora do domínio principal.
Um Event Store deve, idealmente, possuir ferramentas que permitam o reprocessamento sequencial de todos os registros, reaplicando os eventos associados a cada entidade. Esse processo é central ao Event Sourcing e permite que a história contada pelos logs seja novamente reconstituída.

No cenário hipotético de um Event Store que registra todas as transações de crédito e débito e publica esses eventos confirmados para outros domínios, como saldo ou extrato do cliente — que disponibilizam Read Models sumarizados dessas informações —, imagine que um desses domínios sofra algum grau de inconsistência sistêmica ou manual, perdendo total ou parcialmente os dados e comprometendo a integridade das informações.

Nossa aplicação de Event Sourcing deve oferecer mecanismos para reaplicar todos os eventos e reenviá-los sequencialmente ao Event Bus, permitindo que os domínios subsequentes se reconstituam a partir dessas informações temporais, recalculando o saldo atual ou reconstruindo as visualizações de lançamentos.

Essa estratégia é especialmente útil em domínios complexos que exigem rastreabilidade e reconstituições auditáveis, como cadeias farmacêuticas (rastreio de medicamentos), linhas de fabricação, aplicação de descontos, prontuários médicos e históricos de pacientes ou processos de fechamento contábil.

Snapshotting

O modelo transacional propõe que todas as alterações e operações de estado sejam armazenadas para que esses dados possam ser auditados e recompostos ao longo do tempo.

Em um exemplo transacional de uma conta bancária, podemos saber pontualmente o saldo atual da conta, mas perdemos a trilha de eventos que levaram até esse estado.
Depósitos, saques, transferências e estornos, em conjunto, constroem o estado atual do saldo.
Em domínios onde auditabilidade, rastreabilidade ou causalidade são importantes, a ausência desse histórico representa um problema significativo.

No entanto, reconstruir o estado completo pode se tornar computacionalmente caro com o crescimento da base de eventos.
É nesse ponto que surge o conceito de Snapshotting.
Snapshotting é uma técnica de otimização que cria “pontos de restauração” intermediários do estado, como “fotografias” que permitem reconstruí-lo de forma incremental, sem precisar recalcular todas as transações a cada operação.

Um snapshot representa o estado de um agregado ou entidade em um determinado ponto no tempo, acompanhado de um índice do último evento aplicado para gerar aquele estado. Assim, caso seja necessário “reidratar” o estado, o sistema, em vez de processar todo o histórico do início ao fim, pode iniciar o processamento apenas a partir dos eventos ocorridos depois dele.

Por exemplo: a entidade “Saldo”, dentro do agregado “Conta”, pode possuir 1.000.000 de eventos históricos de lançamentos e movimentações.
Para recalcular o saldo, em vez de processar todos os eventos dispersos no banco de dados, o sistema pode gerar um snapshot a cada 10.000 eventos, contendo o saldo consolidado a partir do último evento. Para reconstruir o estado atual, basta carregar o último snapshot e aplicar os eventos posteriores a ele, reduzindo de forma considerável o tempo e o custo computacional de leitura.

No entanto, snapshots devem ser tratados como artefatos derivados e descartáveis, não como fonte primária de verdade. O Event Store continua sendo o “single source of truth”, e os snapshots são mecanismos auxiliares de performance pontual para a operação.

Versionamento e Garantias de Ordem em Consistência Eventual (Last-Write-Wins)

Quando existe a necessidade de reidratar um, alguns ou todos os agregados, precisamos garantir que os domínios consumidores desses eventos atendam a certos critérios para que o processo ocorra da melhor forma possível, assegurando um resultado final consistente das operações.
Dentro do Event Sourcing, o Event Store deve garantir a ordenação local dos eventos de um mesmo agregado, ou seja, todos os eventos relacionados à mesma entidade precisam ser aplicados na sequência temporal em que ocorreram.
Essa ordenação local é o que permite reconstruir estados de forma determinística.

Quando falamos de Event Bus, o Event Store pode garantir a publicação dos eventos à medida que ocorrem, porém a ordem em que serão consumidos não é globalmente garantida por padrão.
Isso significa que eventos publicados em ordem podem chegar fora de ordem em réplicas distintas ou sistemas diferentes, sofrendo variações de tempo de processamento até a devida atualização de estado.
Em arquiteturas event-driven, isso não é uma falha — é o comportamento esperado da consistência eventual.

Em uma operação de saldo, podemos ter várias transações atualizando o saldo de um cliente em um curto intervalo de tempo, mas todas são inseridas com característica temporal e atômica no Event Store e publicadas sequencialmente no Event Bus.
Porém, a ordem de consumo e processamento nos clientes finais pode ocorrer de forma paralela e desordenada, o que pode, por exemplo, gerar uma Read Model final incorreta ao processar eventos mais novos antes de eventos antigos.

Nesse cenário, o modelo Last-Write-Wins (LWW) é uma forma simples de lidar com conflitos de escrita ou reprocessamentos duplicados.
Ele define que, em caso de eventos concorrentes para o mesmo agregado, o último evento válido (por timestamp ou version) deve prevalecer.

Em eventos e sinais produzidos por arquiteturas baseadas em Event Sourcing, cada evento deve possuir um id único e uma version incremental, que identificam a versão do evento a ser comparada.
Isso evita duplicações em sistemas subjacentes e permite evoluir o stream de eventos com segurança.
Esse processo também pode ser conduzido com timestamps Unix, indicando a ordem temporal direta.

Os sistemas que consomem eventos produzidos no Event Bus devem realizar checagens constantes da versão do evento em relação ao estado atual persistido, para evitar sobrescritas indevidas.
Essas verificações podem ser realizadas de forma transacional, com condicionais em nível de código, ou por meio de escritas condicionais em bancos de dados que suportem esse tipo de operação.

Idempotência em Domínios Complexos

A idempotência é a propriedade que permite que uma operação seja executada múltiplas vezes sem alterar o resultado final.
Em sistemas centralizados, isso pode ser garantido por meio de transações ACID.
Mas em arquiteturas distribuídas, onde eventos são propagados de forma assíncrona e cada serviço mantém sua própria consistência, a idempotência precisa ser explicitamente e cuidadosamente projetada.

Em sistemas distribuídos baseados em eventos, ou em arquiteturas assíncronas em geral, a idempotência é um requisito fundamental que permite operar arquiteturas complexas de forma segura.
Isso se deve ao fato de que a entrega e o processamento de eventos são inerentemente inconstantes e não determinísticos, podendo ocorrer em duplicidade, sofrer race conditions ocasionais ou falhar durante a execução e precisar ser reiniciados, o que reforça a necessidade de evitar esforço computacional redundante.

Em arquiteturas baseadas em Event Sourcing, podemos decidir reprocessar todos os eventos de um período específico para recompor projeções e notificações para sistemas subjacentes de forma histórica.
Para que esse processo ocorra corretamente tanto dentro do domínio quanto nos domínios adjacentes, é necessário garantir processos de idempotência distribuída e controle de versão dos eventos, assegurando que eventos já processados não gerem efeitos colaterais ou resultados inconsistentes.
Todos os domínios downstream devem realizar checagens e manter chaves de idempotência fortes e consistentes a todo momento.

Referências

Blueprint - Experimento de Warmup Progressivo com Istio e Argo Rollouts

Thu, 02 Oct 2025 00:00:00 +0000

O gerenciamento de tráfego sincrono durante rollouts de aplicações em Kubernetes pode oferecer algum tipo de ruido operacional e refletir na experiência dos clientes, especialmente quando lidamos com aplicações que necessitam de um período de “warm up” antes de atingir sua performance plena.

Aplicações baseadas em JVM, como Java, Scala e Kotlin, tipicamente enfrentam problemas de performance durante os primeiros momentos de execução. Durante a inicialização, a JVM executa o bytecode no interpretador, consumindo recursos significativos de CPU e resultando em tempos de resposta elevados durante os primeiros momentos do ciclo de vida da aplicação.

Para amenizar esses casos, podemos utilizar o warmUp do Istio Service Mesh para garantir um período de aquecimento seguro para os pods novos que forem sendo criados durante os rollouts.

Warm Up Configuration no Istio

O Istio implementa uma funcionalidade de warm-up através de configurações no DestinationRule que permite controlar a distribuição gradual de tráfego para novos hosts com base em distribuição linear.

Parâmetros Principais

A configuração de warm-up no Istio utiliza três parâmetros principais:

minimumPercent: Define a porcentagem mínima de tráfego que uma nova instância receberá inicialmente
aggression: Controla a velocidade do aumento de tráfego (padrão: 1.0 para crescimento linear)
duration: Período de duração do aquecimento. Quanto tempo até a progessão linear irá levar pra chegar em 100%.

Exemplos coletados

No exemplo utilizamos como apoio para rollout progressivo o Argo Rollouts com estratégia de Canary Releases, para realizar uma estratégia de progressão baseada em tempo que deve ser completada em 5 minutos, com pausas de 60s a cada step.

    strategy:
      canary:
        steps:
        - setWeight: 10
        - pause: { duration: 60s }
        - setWeight: 20
        - pause: { duration: 60s }
        - setWeight: 40
        - pause: { duration: 60s }
        - setWeight: 60
        - pause: { duration: 60s }
        - setWeight: 80
        - pause: { duration: 60s }
        - setWeight: 100

Experiência de Rollout Sem Warm Up

Sem a configuração de warm-up, novos pods recebem imediatamente uma distribuição proporcional do tráfego total. Para um deployment com 6 replicas, um novo pod receberia instantaneamente 16% do tráfego, potencialmente causando, picos de latência, timeouts durante a inicialização, degradação da experiência e burn rate dos SLO’s.

Experiência de Rollout com Warm Up

A experiência com Warm Up foi configurado da seguinte forma:

Algoritmo de Balanceamento: Foi utilizado o algoritmo de Round Robin do Envoy pelas limitações da aplicabilidade do warm up em demais algoritmos
Inicialização: Novo pod recebe apenas 3% do tráfego que deveria receber perante a distribuição padrão
Crescimento Gradual: Tráfego aumenta linearmente, até atingir seu maximo em 5 minutos. Após o período de warm-up de 5 minutos, o pod recebe distribuição normal
Agression: Iremos trabalhar com crescimento de tráfego linear para os novos pods. Valores maiores que 1.0 aceleram o crescimento de tráfego de forma não-linear, enquanto 1.0 mantém linear.

apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: app-warmup
  namespace: production
spec:
  host: myapp.production.svc.cluster.local
  trafficPolicy:
    loadBalancer:
      simple: ROUND_ROBIN
      warmup:
        minimumPercent: 3.0
        duration: 5m
        aggression: 1.0

Limitações Encontrados

Suporte a Load Balancers: Funciona apenas com ROUND_ROBIN e LEAST_REQUEST
Efetividade em Deployments: Menos efetivo quando todos os endpoints são novos simultaneamente
Escala Mínima: Mais efetivo quando poucos pods novos são criados por vez

Msc. Field Notes - Shard Router

Thu, 25 Sep 2025 00:00:00 +0000

Este artigo faz parte de uma organização de um material bruto excedente da minha tese de mestrado. Tem o objetivo de compilar as referencias tecnicas e experimentações práticas.

Este compilado foca no desenvolvimento e análise de um roteador baseado em dar suporte em celulas ou shards de bu;lheads, componente inicial para implementações arquitetura celular.

O projeto se baseia na aplicação simples e conceitual de padrões de arquitetura de roteamento celular ou bulkheads, que implementa roteamento determinístico baseado em hashing consistente. O roteador celular atua como um proxy reverso especializado que direciona requisições de clientes para células (shards) específicas, garantindo que requisições de um mesmo cliente sejam sempre processadas pela mesma célula ou shard.

Hashing Consistente: Para distribuição uniforme e estável de requisições
Roteamento Determinístico: Garantindo que clientes sejam sempre direcionados à mesma célula
Isolamento de Falhas: Através de bulkheads implementados a nível de roteamento
Observabilidade Granular: Com métricas específicas por célula e algoritmo de hash

Fundamentação Teórica

Sharding e Particionamento Horizontal

O sharding, ou particionamento horizontal, é uma técnica consolidada para distribuição de dados e processamento em sistemas distribuídos (Özsu & Valduriez, 2020). Diferentemente do particionamento vertical, que divide dados por colunas ou atributos, o sharding divide o conjunto de dados em partições horizontais baseadas em critérios específicos, como ranges de valores ou funções de hash. Esse conceito é diretamente associado a particionamento de dados fisicamente em bancos de dados, mas não se limita a eles. Iremos seguir aqui pra frente como um critério de segmentação total de infraestrutura, cliente e demais recursos.

graph TD subgraph "Particionamento Vertical" PV1[Tabela Original] PV2[Colunas A, B] PV3[Colunas C, D] PV4[Colunas E, F] PV1 --> PV2 PV1 --> PV3 PV1 --> PV4 end

graph TD subgraph "Sharding" PH1[Dataset Completo] PH2[Shard A
Users 1-1000] PH3[Shard B
Users 1001-2000] PH4[Shard C
Users 2001-3000] PH1 --> PH2 PH1 --> PH3 PH1 --> PH4 end

Análise de Blast Radius e Disponibilidade Sistêmica

Conceito de Blast Radius em Arquiteturas Distribuídas

O blast radius (raio de explosão) representa o escopo de impacto de uma falha em sistemas distribuídos. Em arquiteturas celulares, o blast radius é diretamente proporcional ao número de células distribuídas, oferecendo uma relação matemática clara entre disponibilidade e granularidade de distribuição.

A fórmula fundamental para cálculo de disponibilidade em caso de falha de uma célula é:

Disponibilidade = ((N - F) / N) × 100%

Onde:
- N = Número total de células/shards
- F = Número de células falhando

Impacto da Granularidade na Disponibilidade

A análise quantitativa demonstra como o aumento do número de células reduz exponencialmente o blast radius:

Relação Blast Radius vs. Número de Células

Número de Células	Falhas (1 célula)	Disponibilidade	Blast Radius	Clientes Afetados
3	1	66.7%	33.3%	1/3 da base
5	1	80.0%	20.0%	1/5 da base
10	1	90.0%	10.0%	1/10 da base
25	1	96.0%	4.0%	1/25 da base
50	1	98.0%	2.0%	1/50 da base
100	1	99.0%	1.0%	1/100 da base
1000	1	99.9%	0.1%	1/1000 da base

Trade-offs Operacionais

O aumento da granularidade celular apresenta trade-offs que devem ser considerados:

Benefícios da Alta Granularidade

Redução de Blast Radius:

10 células: Falha afeta 10% dos usuários
100 células: Falha afeta 1% dos usuários
1000 células: Falha afeta 0.1% dos usuários

Isolamento Melhorado:

Falhas ficam contidas em domínios menores
Debugging e troubleshooting mais focado
Rollbacks afetam menos usuários

Custos da Alta Granularidade

Complexidade Operacional vs. Granularidade Celular

Aspecto	Baixa Granularidade (3-10 Células)	Média Granularidade (25-50 Células)	Alta Granularidade (100+ Células)
Complexidade Geral	Moderada	Moderada	Alta
Monitoramento	Simples - Poucos endpoints - Dashboards básicos	Estruturado - Alertas configurados - Métricas agregadas	Sofisticado - Observabilidade avançada - APM necessário
Deployment	Automatizado - CI/CD recomendado - Blue/Green deploy	Automatizado - CI/CD recomendado - Blue/Green deploy	CI/CD Avançado - Canary releases -
Recursos Computacionais	Baixo - 3-10 instâncias - Overhead mínimo	Moderado - 25-50 instâncias - Overhead controlado	Alto - 100+ instâncias - Overhead significativo
Custo Operacional	Baixo	Médio	Alto

Overhead Operacional Detalhado:

Recursos Computacionais: Aumento linear proporcional ao número de células
Monitoramento e Observabilidade: Necessidade de ferramentas sofisticadas (Prometheus, Grafana, Jaeger)
Automação: Obrigatória para granularidade alta, opcional para baixa granularidade
Equipe Especializada: Requisitos crescentes de expertise em SRE e DevOps

Modelo Matemático de Disponibilidade

Para múltiplas falhas simultâneas, o modelo estende-se para:

Disponibilidade = ((N - F) / N) × 100%

Exemplos práticos:
- 100 células, 2 falhas: ((100-2)/100) = 98% disponível
- 100 células, 5 falhas: ((100-5)/100) = 95% disponível
- 1000 células, 10 falhas: ((1000-10)/1000) = 99% disponível

Implementação na Prova de Conceito

A PoC desenvolvida permite configuração dinâmica do número de células através de variáveis de ambiente:

# Configuração para baixo blast radius (alta granularidade)
export SHARD_01_URL="http://cell-001:8080"
export SHARD_02_URL="http://cell-002:8080"
...
export SHARD_100_URL="http://cell-100:8080"

# Resultado: 1% blast radius por falha

O roteador automaticamente distribui a carga entre todas as células configuradas, garantindo que a falha de qualquer célula individual afete apenas 1/N da base de usuários.

Racional prático de blast radius

Com base na análise de blast radius, recomenda-se:

Startups/Pequenas Aplicações: 5-10 células (blast radius: 10-20%)
Aplicações Médias: 25-50 células (blast radius: 2-4%)
Aplicações Críticas: 100+ células (blast radius: <1%)
Sistemas de Alta Disponibilidade: 1000+ células (blast radius: <0.1%)

Implementação e Aspectos Técnicos

A implementação da PoC utiliza sharding baseado em chaves de identificação de clientes, conforme evidenciado na estrutura de configuração:

type ShardRouterImpl struct {
    hashRing    interfaces.HashRing
    shardingKey string
}

func (sr *ShardRouterImpl) GetShardingKey(r *http.Request) string {
    return r.Header.Get(sr.shardingKey)
}

Esta abordagem garante que todas as requisições de um determinado cliente sejam consistentemente direcionadas à mesma célula, propriedade fundamental para manutenção de estado e cache locality (DeCandia et al., 2007).

Hashing Consistente

O hashing consistente, introduzido por Karger et al. (1997), resolve limitações do hashing tradicional em ambientes distribuídos dinâmicos. Enquanto o hashing simples requer redistribuição global de chaves quando nós são adicionados ou removidos, o hashing consistente minimiza a movimentação de dados, redistribuindo apenas uma fração das chaves.

graph TB subgraph "Hashing Tradicional" HT1[3 Servidores] HT2[Key % 3] HT3[Server 0: 33%] HT4[Server 1: 33%] HT5[Server 2: 33%] HT1 --> HT2 HT2 --> HT3 HT2 --> HT4 HT2 --> HT5 HT6[ +1 Servidor] HT7[Key % 4] HT8[75% das chaves
redistribuídas] HT6 --> HT7 HT7 --> HT8 end style HT8 fill:#ffcdd2

graph TB subgraph "Hashing Consistente" HC1[Hash Ring] HC2[Virtual Replicas] HC3[Minimal Redistribution] HC1 --> HC2 HC2 --> HC3 HC4[ +1 Servidor] HC5[25%
das chaves movidas] HC4 --> HC5 end style HC5 fill:#c8e6c9

A PoC implementa múltiplos algoritmos de hash, permitindo análise comparativa de desempenho e distribuição:

const (
    MD5     HashAlgorithm = "MD5"
    SHA1    HashAlgorithm = "SHA1" 
    SHA256  HashAlgorithm = "SHA256"
    SHA512  HashAlgorithm = "SHA512"
    MURMUR3 HashAlgorithm = "MURMUR3"
)

Estudos empíricos realizados com a implementação revelam variações significativas na qualidade da distribuição entre algoritmos. O SHA1 apresentou a menor variância (121.67) e diferença entre melhor e pior shard (2.7%), enquanto algoritmos não-criptográficos como FNV64 demonstraram distribuição inadequada (variância de 156,116.33).

graph TB subgraph "Comparação" CAH1[Input: client-id] subgraph "Algoritmos de Hashing" AC1[SHA1
✅ Melhor Distribuição
Desvio: 11.03] AC2[SHA256
⚠️ Distribuição Moderada
Desvio: 64.60] AC3[SHA512
✅ Boa Distribuição
Desvio: 28.31] AC4[MD5
⚠️ Distribuição Aceitável
Desvio: 42.05] ANC1[MURMUR3
❌ Distribuição Irregular
Desvio: 95.84] ANC2[FNV64
❌ Distribuição Inadequada
Desvio: 395.12] end subgraph "Distribuição nos Shards" DS1[Shard A: 32-34%] DS2[Shard B: 30-35%] DS3[Shard C: 31-37%] end CAH1 --> AC1 CAH1 --> AC2 CAH1 --> AC3 CAH1 --> AC4 CAH1 --> ANC1 CAH1 --> ANC2 AC1 --> DS1 AC1 --> DS2 AC1 --> DS3 end style AC1 fill:#c8e6c9 style AC3 fill:#e8f5e8 style AC2 fill:#fff3e0 style AC4 fill:#fff3e0 style ANC1 fill:#ffcdd2 style ANC2 fill:#ffcdd2

Bulkheads e Isolamento de Falhas

O padrão Bulkhead, inspirado na construção naval, propõe a compartimentalização de sistemas para conter falhas (Nygard, 2018). Na arquitetura celular, cada célula funciona como um bulkhead independente, onde falhas em uma célula não propagam para outras células do sistema.

graph TB subgraph "Arquitetura sem Bulkheads" AB1[Load Balancer] AB2[Shared Resource Pool] AB3[Service A] AB4[Service B] AB5[Service C] AB6[💥 Falha em cascata] AB1 --> AB2 AB2 --> AB3 AB2 --> AB4 AB2 --> AB5 AB3 -.->|falha propaga| AB4 AB4 -.->|falha propaga| AB5 AB5 --> AB6 end style AB6 fill:#ffcdd2

graph TB subgraph "Arquitetura com Bulkheads (Celular)" BC1[Shard Router] subgraph "Célula B" APPB[App B] --> DBB[Database B] end subgraph "Célula A - Falha Isolada" APPA[App A] --> DBA[Database A] --> FALHA[💥 Falha no Shard] end subgraph "Célula C" APPC[App C] --> DBC[Database C] end BC1 --> APPA BC1 --> APPB BC1 --> APPC end style FALHA fill:#ffcdd2

A implementação demonstra este isolamento através da estrutura de proxy reverso:

func (ph *ProxyHandler) ServeHTTP(w http.ResponseWriter, r *http.Request) {
    shardKey := ph.router.GetShardingKey(r)
    shardURL := ph.router.GetShardHost(shardKey)
    
    // Isolamento: falha em um shard não afeta outros
    client := &http.Client{}
    resp, err := client.Do(proxyReq)
    if err != nil {
        http.Error(w, err.Error(), http.StatusBadGateway)
        return
    }
}

Observabilidade e Métricas

A observabilidade é crucial para operação de sistemas distribuídos (Majors et al., 2022). A PoC implementa coleta de métricas usando Prometheus, fornecendo visibilidade sobre:

Distribuição de requisições por shard
Taxa de sucesso/falha por célula
Latência de processamento
Utilização de recursos

graph TB subgraph "Sistema Observável" SO1[Cellular Router] subgraph "Células" SC1[Célula A] SC2[Célula B] SC3[Célula C] end subgraph "Coleta de Métricas" CM1[Prometheus Metrics] CM2[Request Counter] CM3[Response Counter] CM4[Health Checks] end subgraph "Visualização" SV1[Grafana Dashboard] SV2[📊 Distribuição por Shard] SV3[📈 Taxa de Sucesso/Falha] SV4[⏱️ Latência por Célula] SV5[🎯 Detecção de Hotspots] end SO1 --> SC1 SO1 --> SC2 SO1 --> SC3 SC1 --> CM1 SC2 --> CM1 SC3 --> CM1 CM1 --> CM2 CM1 --> CM3 CM1 --> CM4 CM1 --> SV1 SV1 --> SV2 SV1 --> SV3 SV1 --> SV4 SV1 --> SV5 end style CM1 fill:#e3f2fd style SV1 fill:#e8f5e8 style SV5 fill:#fff3e0

type PrometheusMetricsRecorder struct {
    requestsCounter prometheus.CounterVec
    responseCounter prometheus.CounterVec
}

func (pm *PrometheusMetricsRecorder) RecordRequest(shard string) {
    pm.requestsCounter.WithLabelValues(shard).Inc()
}

Arquitetura da Solução

Visão Geral do Sistema

A arquitetura implementada na PoC segue o padrão de proxy reverso com roteamento baseado em hashing consistente. O sistema é composto por três camadas principais:

Camada de Roteamento: Responsável por receber requisições e determinar o shard de destino
Camada de Hash Ring: Implementa o algoritmo de hashing consistente
Camada de Células: Conjunto de serviços independentes (shards)

graph TB subgraph "Cliente" C1[Aplicação Cliente] C2[Header: client-id] end subgraph "Camada de Roteamento" R1[HTTP Server :8080] R2[Proxy Handler] R3[Shard Router] end subgraph "Camada Hash Ring" H1[Consistent Hash Ring] H2[SHA-512 Algorithm] H3[Virtual Replicas] end subgraph "Células (Shards)" S1[Célula A
Domain Shard] S2[Célula B
Domain Shard] S3[Célula C
Domain Shard] SN[Célula N
Domain Shard] end subgraph "Observabilidade" M1[Prometheus Metrics] M2[Health Checks] end C1 --> C2 C2 --> R1 R1 --> R2 R2 --> R3 R3 --> H1 H1 --> H2 H2 --> H3 H3 --> S1 H3 --> S2 H3 --> S3 H3 --> SN R2 --> M1 R1 --> M2 style S1 fill:#e1f5fe style S2 fill:#e1f5fe style S3 fill:#e1f5fe style SN fill:#e1f5fe

Fluxo de Processamento

O fluxo de processamento de uma requisição na arquitetura celular segue as seguintes etapas:

sequenceDiagram participant C as Cliente participant P as Proxy Router participant H as Hash Ring participant S as Shard (Célula) participant M as Métricas C->>P: HTTP Request + client-id header P->>P: Extrair sharding key P->>H: GetNode(client-id) H->>H: Calcular hash SHA-512 H->>H: Localizar no ring H-->>P: URL do shard destino P->>M: Registrar requisição P->>S: Proxy request S-->>P: Response P->>M: Registrar resposta P-->>C: HTTP Response

Algoritmo de Distribuição

O algoritmo de hashing consistente implementado utiliza réplicas virtuais para melhorar a distribuição uniforme das chaves:

graph LR subgraph "Hash Ring" direction TB R1[Replica Shard-1-0
Hash: 0x1A2B] R2[Replica Shard-2-0
Hash: 0x3C4D] R3[Replica Shard-1-1
Hash: 0x5E6F] R4[Replica Shard-3-0
Hash: 0x7890] R5[Replica Shard-2-1
Hash: 0x9ABC] R6[Replica Shard-3-1
Hash: 0xDEF0] end K1[Key: user-123
Hash: 0x4567] --> R3 K2[Key: user-456
Hash: 0x8901] --> R6 K3[Key: user-789
Hash: 0x2345] --> R2 style R1 fill:#ffcdd2 style R3 fill:#ffcdd2 style R2 fill:#c8e6c9 style R5 fill:#c8e6c9 style R4 fill:#e1bee7 style R6 fill:#e1bee7

Análise de Desempenho dos Algoritmos de Hash

Metodologia de Avaliação

Para validar a eficácia dos diferentes algoritmos de hash na distribuição uniforme de chaves, foram realizados experimentos com 1 milhão de chaves UUID v4 distribuídas entre 3 shards. As chaves UUID v4 foram escolhidas por sua natureza aleatória e representatividade em cenários reais de produção. Os critérios de avaliação incluíram:

Uniformidade de distribuição: Medida pelo desvio padrão da distribuição
Variância: Indicador de dispersão dos valores
Diferença máxima: Distância entre o shard com maior e menor carga

Resultados Experimentais

A Tabela 1 apresenta os resultados comparativos dos algoritmos testados:

Análise Comparativa de Algoritmos de Hash

Algoritmo	Desvio Padrão	Variância	Melhor Shard (%)	Pior Shard (%)	Diferença
SHA1	11.03	121.67	32.0%	34.7%	2.7%
SHA512	28.31	801.67	30.5%	37.2%	6.7%
SHA256	64.60	4173.67	26.3%	41.9%	15.6%
MD5	42.05	1768.33	28.2%	38.5%	10.3%
MURMUR3	95.84	9185.33	23.1%	48.2%	25.1%

Discussão dos Resultados

Os resultados evidenciam que o SHA1 apresenta a melhor distribuição uniforme, com menor desvio padrão (11.03) e diferença entre shards (2.7%). Este comportamento contraria expectativas iniciais que favoreciam SHA-512 devido à maior complexidade criptográfica.

O SHA-512, embora apresente distribuição aceitável (desvio padrão: 28.31), demonstra performance inferior ao SHA1 em termos de uniformidade. Contudo, mantém características criptográficas superiores, relevantes para cenários que exigem resistência a ataques de hash.

Algoritmos não-criptográficos como MURMUR3 apresentaram distribuição menos uniforme que esperado, contradizendo literatura que sugere sua superioridade em aplicações de hashing distribuído (Appleby, 2008).

Propriedades da Arquitetura Celular

Determinismo de Roteamento

Uma propriedade fundamental da arquitetura celular é o determinismo de roteamento. Requisições com a mesma chave de sharding são consistentemente direcionadas à mesma célula, independentemente do momento da requisição ou estado do sistema.

func (sr *ShardRouterImpl) GetShardHost(key string) string {
    node := sr.hashRing.GetNode(key)
    fmt.Printf("[%s] Mapping key %s to host: %s\n", 
               sr.hashRing.GetHashAlgorithm(), key, node)
    return node
}

Esta propriedade é essencial para:

Manutenção de cache local por célula
Consistência de sessão de usuário
Otimização de consultas relacionadas por cliente

Escalabilidade Horizontal

A arquitetura permite adição dinâmica de células sem interrupção do serviço. O uso de hashing consistente garante redistribuição mínima de chaves (aproximadamente K/N chaves movidas, onde K é o total de chaves e N o número de nós).

Tolerância a Falhas

O isolamento entre células proporciona contenção de falhas. A indisponibilidade de uma célula afeta apenas os clientes mapeados para aquela célula específica, mantendo o restante do sistema operacional.

Observabilidade Granular

O roteamento determinístico facilita observabilidade granular por célula, permitindo:

Métricas específicas por domínio de clientes
Detecção de hotspots de tráfego
Análise de padrões de uso por segmento

Implementação e Aspectos Técnicos

Padrões de Projeto Aplicados

A implementação utiliza diversos padrões consolidados:

Strategy Pattern: Para algoritmos de hash intercambiáveis

type HashAlgorithm string
const (
    SHA512  HashAlgorithm = "SHA512"
    SHA256  HashAlgorithm = "SHA256"
    // ...
)

Proxy Pattern: Para roteamento transparente de requisições

type ProxyHandler struct {
    router          interfaces.ShardRouter
    metricsRecorder interfaces.MetricsRecorder
}

Factory Pattern: Para criação de componentes configuráveis

func NewConsistentHashRing(numReplicas int) interfaces.HashRing {
    ring := &ConsistentHashRing{
        Nodes:       []Node{},
        NumReplicas: numReplicas,
    }
    ring.configureHashAlgorithm()
    return ring
}

Limitações e Trabalhos Futuros

Limitações Identificadas

Rebalanceamento: Não há implementação automática de rebalanceamento quando células ficam sobrecarregadas
Descoberta de Serviços: Configuração estática de shards limita elasticidade
Consistência Cross-Cell: Transações que envolvem múltiplas células não são suportadas
Circuit Breaker: Ausência de proteção contra cascata de falhas

Extensões Propostas

Auto-scaling Celular: Algoritmos para adição/remoção automática de células baseado em métricas de carga
Service Mesh Integration: Integração com Istio/Linkerd para descoberta de serviços e políticas de tráfego
Distributed Tracing: Implementação de rastreamento distribuído para análise de latência cross-cell
Consensus Protocols: Integração com Raft/PBFT para coordenação entre células

Referências

Appleby, A. (2008). MurmurHash3. SMHasher. https://github.com/aappleby/smhasher

DeCandia, G., Hastorun, D., Jampani, M., Kakulapati, G., Lakshman, A., Pilchin, A., … & Vogels, W. (2007). Dynamo: Amazon’s highly available key-value store. ACM SIGOPS operating systems review, 41(6), 205-220. https://doi.org/10.1145/1323293.1294281

Karger, D., Lehman, E., Leighton, T., Panigrahy, R., Levine, M., & Lewin, D. (1997). Consistent hashing and random trees: Distributed caching protocols for relieving hot spots on the World Wide Web. Proceedings of the twenty-ninth annual ACM symposium on Theory of computing, 654-663. https://doi.org/10.1145/258533.258660

Majors, C., Fong-Jones, L., & Miranda, G. (2022). Observability engineering: Achieving production excellence. O’Reilly Media.

Newman, S. (2015). Building microservices: Designing fine-grained systems. O’Reilly Media.

Nygard, M. T. (2018). Release it!: Design and deploy production-ready software (2nd ed.). Pragmatic Bookshelf.

Özsu, M. T., & Valduriez, P. (2020). Principles of distributed database systems (4th ed.). Springer. https://doi.org/10.1007/978-3-030-26253-2

Richardson, C. (2018). Microservices patterns: With examples in Java. Manning Publications.

System Design - Teorema PACELC

Sun, 14 Sep 2025 00:00:00 +0000

Esse texto é um complemento ao capítulo anterior sobre ACID, BASE e Teorema CAP, e apresenta uma evolução conceitual do modelo teórico do CAP, incluindo as críticas que surgiram com a evolução dos sistemas distribuídos e de seus componentes. O PACELC é um conceito mais moderno, que ajuda a compreender algumas lacunas que o CAP não cobre.

Após uma boa assimilação das classificações AP, CA, CP do CAP, podemos aprofundar o entendimento nos apêndices trazidos pelo PACELC.

O Teorema PACELC

O Teorema PACELC foi proposto por Daniel Abadi em 2010, na Universidade de Yale, e nos ajuda a entender sistemas distribuídos para além do que é proposto pelo Teorema CAP. O Teorema CAP, como já vimos, estabelece que um sistema, mediante uma partição de rede, precisa escolher entre consistência e disponibilidade. Esse modelo foi — e ainda é — extremamente importante para nortear decisões arquiteturais e de engenharia em diversos contextos, mas deixa algumas lacunas conceituais em sistemas modernos, principalmente quanto ao comportamento do sistema ao considerar a Partition Tolerance. Por exemplo: o que aconteceria com um sistema quando não houver falhas de rede?

O PACELC amplia esse entendimento no contexto de bancos de dados distribuídos ao levantar uma nova questão: o que acontece quando não há falhas de rede e não há particionamento entre os nós do sistema? Nesses cenários, é possível operar em diferentes níveis de consistência conforme a necessidade. Assim, o modelo nos ajuda a refletir: o que o sistema deve priorizar quando está funcionando corretamente? E, de forma complementar, o que ele deve priorizar quando ocorre um particionamento entre os nós? O teorema nos ajuda a responder esses questionamentos de forma mais detalhada.

Teorema PACELC vs Teorema CAP

Como vimos anteriormente, o Teorema CAP diz que quando ocorre uma Partição de Rede (P) entre os nós do sistema, é necessário escolher entre Consistência (C) ou Disponibilidade (A). Esse raciocínio é muito útil para a escolha de tecnologias que envolvem esses dois trade-offs, mas ainda deixa em aberto o requisito não funcional de como o sistema deve operar quando não há partições de rede.

O PACELC funciona como uma extensão do CAP, propondo o seguinte racional: se houver partição (P), devemos escolher entre Disponibilidade (A) e Consistência (C); Else (E), ou seja, se não houver partição, escolhemos entre Latência (L) e Consistência (C). O teorema mostra que, mesmo em condições normais, sem partições, ainda é preciso tomar decisões difíceis ao projetar a arquitetura. Ou priorizamos a garantia de uma consistência forte, pagando o preço de mais latência, ou abrimos mão de maiores níveis de consistência para reduzir o tempo de resposta e otimizar a performance das operações.

Em momentos de falha, decidimos entre disponibilidade e consistência. Fora deles, optamos entre consistência forte, que pode custar latência, e consistência eventual, que otimiza a performance, mas sem garantias imediatas de consistência.

Esse raciocínio aproxima o modelo da realidade dos sistemas modernos, onde temos redes geograficamente distribuídas, replicação de dados e sharding e particionamento.

Imagine um banco de dados global: se ele quiser garantir que todas as réplicas estejam sempre sincronizadas antes de confirmar uma operação (consistência forte), cada escrita será mais lenta devido à latência de rede. Já se ele aceitar consistência eventual, poderá responder mais rápido, mas correrá o risco de que um usuário no Brasil veja um dado diferente de outro usuário na Espanha por algum tempo.

Em resumo, os dois teoremas não são excludentes, mas complementares. O PACELC amplia o CAP ao analisar não apenas os cenários de falha, mas também o comportamento do sistema em situações normais, conectando os padrões CP (Consistency + Partition Tolerance) e AP (Availability + Partition Tolerance) com as escolhas de Latência (L) e Consistência (C) fora das partições.

Aplicações do PACELC

O Teorema PACELC se tornou uma forma prática de classificar sistemas distribuídos e suas bases de dados. Por exemplo, o Amazon DynamoDB é conhecido como PA/EL — ou seja, prefere disponibilidade durante partições (PA) e latência baixa em condições normais (EL). Já o Google Spanner é classificado como PC/EC, pois prefere consistência tanto durante partições quanto no funcionamento cotidiano, aceitando pagar o preço da latência.

Assim como no CAP, em que temos classificações como AP, CP ou AC, no PACELC também é possível categorizar os bancos de dados em diferentes combinações, como PA/EL, PC/EL, PA/EC e PC/EC, dependendo das escolhas de trade-offs.

PA/EL (On Partition, Availability; Else, Latency)

O modelo PA/EL descreve um sistema que, em condições normais (sem partição de rede), prioriza a latência em vez da consistência. Esse tipo de sistema busca garantir baixa latência nas operações, mesmo que isso signifique abrir mão de uma consistência forte. Else (E): quando ocorre uma partição de rede, o sistema prioriza a disponibilidade (A) em vez da consistência (C). Em outras palavras, reforça o modelo de consistência eventual, no qual todos os nós continuam respondendo às requisições independentemente do rompimento da partição, ainda que as réplicas não estejam totalmente sincronizadas.

Esses bancos de dados são projetados para oferecer alta performance nas operações de escrita de forma resiliente, mas aceitam que diferentes usuários possam ver versões ligeiramente diferentes dos dados por algum tempo, até que a partição seja resolvida. É o caso de tecnologias como DynamoDB e Cassandra, amplamente utilizadas em cenários de grande escala, onde performance global e disponibilidade são mais importantes que a consistência absoluta.

PC/EL (On Partition, Consistency; Else, Latency)

No modelo PC/EL, temos sistemas que, em seu funcionamento normal, priorizam a latência e o alto throughput ao custo da consistência. Nesse cenário, o sistema reduz o nível de consistência operacional para manter tempos de resposta rápidos e operações de escrita otimizadas.

Else (E): em caso de particionamento, o sistema passa a priorizar a consistência (C). Isso significa que, em uma situação de falha, o sistema pode ficar indisponível até que o cluster recupere o consenso e volte a operar, garantindo a integridade dos dados mesmo ao custo da disponibilidade temporária.

É uma escolha intermediária, em que os sistemas em questão não possuem soluções confiáveis de resolução de conflitos em grandes volumes de dados, funcionando apenas dentro do fluxo transacional previsto. Por isso, é preferível tornar o serviço indisponível do que lidar com uma parcela de dados que eventualmente nunca se tornaria consistente.

Esse modelo é interessante quando a consistência mínima durante falhas é inegociável, mas, durante a operação normal, o objetivo é priorizar alto desempenho nas operações de escrita e leitura. O sistema aceita consistência eventual apenas quando todos os nós estão disponíveis, exigindo processos contínuos de health checks e heartbeats entre eles para validar o status antes de realizar operações. Caso contrário, prefere ficar totalmente inoperante.

PA/EC (On Partition, Availability; Else, Consistency)

O modelo PA/EC descreve sistemas que, em condições normais de operação, priorizam a consistência forte, garantindo que todas as réplicas do sistema mantenham sempre a mesma versão do dado.

Else (E): em caso de falhas ou particionamentos de rede, o sistema prioriza a disponibilidade (A), aceitando operações de escrita e leitura mesmo que existam divergências temporárias entre as réplicas.

Normalmente, esses sistemas contam com algoritmos complexos de CRDTs (Conflict-Free Replicated Data Types), que fazem a gestão de conflitos entre diferentes atualizações de dados em nós distribuídos. Esse modelo é menos comum, mas pode aparecer em contextos híbridos de microserviços, nos quais a experiência do usuário não pode parar mesmo com falhas parciais, mas em que a regra de negócio e a criticidade operacional exigem que, quando a rede está saudável, todos os dados permaneçam rigorosamente sincronizados.

Em resumo, esse modelo assume a consistência eventual apenas como um fallback da consistência forte em último caso.

PC/EC (On Partition, Consistency; Else, Consistency)

O modelo PC/EC descreve sistemas que são mais conservadores em relação à consistência dos dados. Em operações normais, o sistema também prioriza a consistência em vez da latência, aceitando um maior custo de tempo de resposta em troca da garantia de que a última versão do dado esteja disponível em todos os nós. Else (E): durante uma partição de rede, o sistema prioriza a consistência (C) em vez da disponibilidade (A), assumindo que é melhor falhar temporariamente do que operar com consistência eventual em algum nível.

Esse comportamento é típico em sistemas nos quais a precisão dos dados é a qualidade mais importante. É a escolha natural para sistemas bancários, coordenação de clusters e transações críticas, onde ver dados incorretos por alguns milissegundos pode gerar prejuízos enormes.

Podemos encontrar esse modelo em bancos SQL tradicionais, no etcd e também em bancos transacionais geograficamente distribuídos, como o Google Spanner.

Comparações do PACELC

A seguir, temos uma tabela comparativa de alguns flavors de bancos ditribuídos que estão inerentes a trabalhos com partição, e onde cada uma delas se encontra dentro dos itens do PACELC.

Sistema / Banco de Dados	PAC (durante partição)	ELC (sem partição)	Classificação	Observação
Amazon DynamoDB	A (disponibilidade)	L (baixa latência, consistência eventual por padrão)	PA/EL	Eventual consistency como default, mas suporta “strong reads” opcionais.
Cassandra	A (disponibilidade)	L (baixa latência, consistência eventual por padrão)	PA/EL	Modelo baseado no Dynamo, otimizado para disponibilidade e baixa latência global.
MongoDB	A (se configurado com `w=1`) ou C (com majority write concern)	L (eventual consistency em réplicas secundárias)	PA/EL ou PC/EL	Flexível; o trade-off depende do write concern e read concern.
Google Spanner	C (consistência forte global)	C (mesmo sem partição, prioriza consistência)	PC/EC	Usa TrueTime para garantir consistência serializável global, com custo de latência.
Azure Cosmos DB	A (disponibilidade)	L/C (configurável: eventual, bounded staleness, session, consistent prefix, strong)	PA/ELC	Oferece 5 níveis de consistência configuráveis.
Apache Kafka	A (disponibilidade)	L (prioriza throughput e baixa latência)	PA/EL	Garantias de consistência são fracas; foco em disponibilidade e velocidade.
Etcd	C (consistência forte)	C (consistência forte)	PC/EC	Voltado para consistência forte, usado em sistemas críticos de coordenação.
ZooKeeper	C (consistência forte)	C (consistência forte)	PC/EC	Voltado para consistência forte, usado em sistemas críticos de coordenação.
CockroachDB	C (prioriza consistência em partições)	C (consistência forte via consenso Raft)	PC/EC	Inspirado no Spanner, mantém consistência global em troca de latência mais alta.
Redis em Cluster Mode	A (disponibilidade, pode perder dados em falhas)	L (baixa latência com replicação assíncrona)	PA/EL	Focado em velocidade; consistência forte não é garantida em partições ou failover.
Amazon RDS (Multi-AZ)	C (replicação síncrona entre zonas, prioriza consistência)	C (dados consistentes entre réplicas antes de confirmar)	PC/EC	Designado para workloads transacionais, garantindo consistência e durabilidade.

Referências

Consistency Tradeoffs in Modern Distributed Database System Design

PACELC design principle

PACELC: A extensão do Teorema CAP

PACELC Theorem

PACELC Theorem Explained: Distributed Systems Series

System Design Interview Basics: CAP vs. PACELC

PACELC Theorem

PACELC Theorem & Distributed Databases

Understanding Eventual Consistency in DynamoDB