Resiliência além do óbvio: O princípio do trabalho constante

TLDR; Este post é sobre uma das coisas que mais explodiram minha cabeça desde que comecei a trabalhar na AWS com sistemas distribuídos de larga escala: muitas das abordagens que a nossa intuição de engenharia jura que aumentam a resiliência são exatamente as que nos deixam mais vulneráveis. Fallbacks, modos de emergência, “planos B” que só rodam quando algo dá errado — parecem prudência, mas embutem uma armadilha. Nesse post vamos discutir uma alternativa para isso, o princípio do trabalho constante.

Deixa eu começar com uma pergunta que parece boba. Quando o seu sistema falha, ele passa a fazer mais trabalho ou menos? Pare um segundo nisso. A maioria dos sistemas que projetamos responde “mais” — quando o cache cai, batemos no banco; quando um nó morre, os outros assumem a carga dele; quando algo dá erro, logamos dez vezes mais. E aí está o problema: nós projetamos sistemas que fazem mais trabalho justamente no pior momento possível, quando já estão sob estresse. É como um carro cujo freio exige mais força quanto mais rápido você vai.

Essa inversão é a raiz do que chamamos de comportamento bimodal — e entendê-la muda a forma como você projeta a arquitetura da sua aplicação.

O desenvolvimento de sistemas distribuídos apresenta desafios únicos que são bem diferentes dos encontrados em sistemas monolíticos ou em aplicações rodando em um único servidor. Sistemas distribuídos são, por natureza, compostos por múltiplos componentes que operam em diferentes servidores, regiões ou até mesmo continentes. Isso implica que os sistemas distribuídos precisam lidar com latências de rede, falhas de componentes, inconsistências de dados e variabilidade de carga em uma escala muito maior do que os sistemas centralizados.

A complexidade desses sistemas é exacerbada pela necessidade de garantir alta disponibilidade, consistência e resiliência, mesmo quando partes do sistema falham ou se tornam inacessíveis. Essas falhas podem ser desde um único servidor que para de responder, até uma zona de Disponibilidade inteira que fica offline. O desafio, portanto, não é apenas construir sistemas que funcionem sob condições normais, mas que continuem operando de maneira confiável e previsível mesmo sob as condições mais adversas.

Porém, um dos desafios mais sutis no desenvolvimento de sistemas distribuídos é evitar a criação de comportamentos bimodais. Esses comportamentos surgem quando um sistema alterna entre modos de operação normais e modos de fallback em resposta a falhas ou mudanças na carga. Embora possa parecer uma boa ideia ter modos distintos para lidar com condições adversas, na prática, esses modos frequentemente introduzem novos problemas, tornando o sistema mais complexo, menos previsível e, paradoxalmente, menos resiliente.

O que são comportamentos bimodais?

Comportamentos bimodais referem-se à capacidade de um sistema de operar em dois modos distintos: um modo normal, onde o sistema funciona como esperado, e um modo de falha ou fallback, que é ativado em resposta a falhas, sobrecarga ou outras condições adversas, que nem sempre são falhas. A ideia por trás dos comportamentos bimodais é fornecer um caminho alternativo para a execução de operações críticas quando o modo normal não está disponível, não é viável ou uma tarefa que é executada somente eventualmente está em operação.

Por exemplo, considere um serviço de e-commerce que normalmente acessa informações de produtos a partir de um cache em memória. Se o cache falhar ou se tornar indisponível, o sistema pode entrar em um modo de fallback onde consulta diretamente o banco de dados para obter as informações necessárias. Esse é um exemplo clássico de comportamento bimodal. Quando tudo está operando bem, a aplicação se alimenta do cache, mas quando o cache falha por qualquer motivo ou começa a apresentar uma grande taxa de cache miss é que começam os problemas. Vamos ver o diagrama abaixo:

Outros exemplos de comportamento bimodais são:

• Consumo de recursos eventuais - processos que são executados apenas periodicamente e são desligados quando não estão em uso. Isso pode criar um comportamento bimodal se o pico de carga no sistema coincidir com o processo periódico em execução, sobrecarregando o sistema.
• Garbage collection em Java - A natureza imprevisível da coleta de lixo do Java pode introduzir desempenho bimodal, com algumas solicitações sofrendo atrasos significativos devido a pausas de GC.
• Saídas de logs de erros - saídas de logs quando o sistema está operando normalmente tem por exemplo 1kb de logs sendo gerado, mas na ocorrência de uma falha possui uma saída de logs de 10kb por estar imprimindo muito mais informações do que está ocorrendo. Isso também pode ser um problema se a aplicação já está em sobrecarga, principalmente se for de I/O.

Problemas com Comportamentos Bimodais

Embora os comportamentos bimodais possam parecer uma solução lógica para lidar com falhas, eles introduzem uma série de desafios e riscos:

1. Complexidade aumentada: Ter modos distintos de operação adiciona complexidade ao sistema. Essa complexidade se manifesta tanto no código quanto na lógica operacional, tornando o sistema mais difícil de entender, manter e testar.
2. Imprevisibilidade: Transições entre modos podem ser difíceis de prever e testar. Um modo de fallback pode funcionar bem em testes isolados, mas se comportar de forma inesperada em produção, especialmente sob condições de alta carga.
3. Falhas amplificadas: O modo de fallback pode acabar amplificando o impacto de uma falha em vez de mitigá-lo. Por exemplo, se o fallback for consultar um banco de dados diretamente em vez de usar um cache, uma falha massiva no cache pode sobrecarregar o banco de dados e causar uma falha em cascata.
4. Dificuldade de teste: Testar adequadamente o comportamento bimodal é difícil, porque o modo de fallback pode ser raramente ativado em produção. Quando ativado, as condições reais podem ser muito diferentes das condições de teste, levando a falhas imprevistas.

E os fallbacks ? Podem atrapalhar mais do que ajudam

No assunto da resiliência é impossível não falar de fallbacks. E antes de entrar mais no assunto vamos começar com algumas definições relacionadas: fallback e failover. Failover é executar a atividade novamente em uma cópia diferente do endpoint ou, de preferência, execute múltiplas cópias paralelas da atividade para aumentar as chances de que pelo menos uma delas seja bem-sucedida. Fallback é utilizar um mecanismo diferente para obter o mesmo resultado.

Estratégias de fallback são frequentemente vistas como uma solução para aumentar a resiliência de sistemas distribuídos. A lógica por trás dos fallbacks é simples: se um componente do sistema falhar, outro pode assumir suas funções, garantindo que o sistema continue a operar. No entanto, na prática, os fallbacks muitas vezes mais atrapalham do que ajudam, especialmente em sistemas distribuídos complexos.

Fallback em um checkout de e-commerce

Imagine um checkout que normalmente chama um serviço de antifraude síncrono antes de aprovar um pedido. Enquanto tudo está saudável, o fluxo é simples: o pedido chega, o antifraude responde, o pagamento é autorizado e a compra segue. Mas quando o antifraude começa a falhar, a tentação é criar um “modo especial”: tentar uma segunda API, consultar regras locais antigas, aumentar o timeout ou colocar pedidos em uma fila de revisão manual.

Esse fallback parece prudente, mas mudou a natureza do trabalho no caminho mais crítico da aplicação. O checkout deixa de fazer uma decisão síncrona e bem conhecida e passa a acumular estados intermediários, filas, exceções operacionais e decisões ambíguas justamente durante o incidente. A falha de um serviço externo vira uma mudança de comportamento dentro do seu domínio de negócio.

Embora essa estratégia possa manter algumas vendas fluindo no curto prazo, ela pode levar a uma série de problemas:

• Latência aumentada no caminho crítico: timeouts maiores e múltiplas tentativas fazem o cliente esperar mais exatamente quando o sistema já está instável.
• Estados ambíguos de negócio: pedidos ficam “pendentes de revisão”, “pré-aprovados”, “autorizados sem antifraude” ou “aguardando reconciliação”, criando caminhos operacionais que raramente são exercitados.
• Trabalho manual e filas represadas: o fallback desloca a carga para outro sistema ou para pessoas, acumulando uma dívida operacional que precisa ser paga depois do incidente.

Repare que a fila de revisão manual não remove o trabalho; ela apenas empurra esse trabalho para depois. Se o incidente durar tempo suficiente, a recuperação deixa de ser apenas “voltar o antifraude” e passa a incluir uma segunda pergunta: quem vai pagar a dívida acumulada sem derrubar o restante do sistema?

Esses problemas exemplificam como comportamentos bimodais podem, paradoxalmente, reduzir a resiliência de um sistema em vez de aumentá-la.

O anti-padrão aparece quando o código tenta “salvar” a compra fazendo outro tipo de trabalho:

# ❌ Checkout bimodal: sob falha, muda a decisão de negócio
def finalizar_pedido(pedido):
    try:
        antifraude.aprovar(pedido)
    except AntifraudeIndisponivel:
        pedido.status = "pendente_revisao_manual"
        fila_revisao.enviar(pedido)
        return "pedido_recebido"  # parece sucesso, mas virou outro fluxo

    pagamento.autorizar(pedido)
    return "pedido_aprovado"

# ✅ Falha explícita e uniforme: não cria um modo escondido
def finalizar_pedido(pedido):
    try:
        antifraude.aprovar(pedido)
    except AntifraudeIndisponivel:
        raise CheckoutTemporariamenteIndisponivel()

    pagamento.autorizar(pedido)
    return "pedido_aprovado"

No primeiro caso, o sistema continua aceitando trabalho que não consegue concluir pelo caminho normal. No segundo, ele preserva a semântica do fluxo: ou o pedido passa pelo caminho conhecido, ou falha de forma explícita e controlada.

Fallback em redistribuição imediata de shards após falha

Outro padrão que aparece em sistemas distribuídos é a recuperação que compete com o tráfego real. Imagine um cluster particionado por shards. Em operação normal, cada nó atende sua fatia de tráfego e mantém seu estado quente em memória. Quando um nó cai, os demais não recebem apenas mais requisições; eles também começam a copiar partições, recalcular ownership, reconstruir índices e aquecer caches locais para absorver o que foi perdido.

Perceba a inversão, a falha reduziu a capacidade disponível e, ao mesmo tempo, acionou trabalho extra de recuperação. O sistema tenta se curar fazendo mais CPU, mais rede, mais I/O e mais alocação de memória exatamente quando tem menos folga. O resultado esperado era uma degradação graciosa; o resultado real pode ser uma segunda onda de falhas, agora causada pelo próprio mecanismo de recuperação.

Esse tipo de incidente destaca a lição central deste post: o modo de recuperação foi acionado exatamente no pior momento possível — sob estresse máximo — e, em vez de proteger o sistema, tornou-se o próprio vetor da falha generalizada.

O fallback que apaga o trabalho do cliente

O perigo de um modo de emergência não é só sobrecarregar outro componente — é tomar decisões destrutivas com base em informação incompleta. Imagine um serviço de carrinho de compras que, ao receber erros de um serviço de catálogo sobrecarregado, interpretou “não consegui consultar este produto” como “este produto não existe mais” e removeu os itens dos carrinhos dos clientes em massa. O fallback fez um trabalho diferente do normal, e esse trabalho diferente foi ativamente prejudicial. A lição é dura: um modo de fallback jamais deve tratar “falha ao obter o dado” como “dado ausente” — a ausência de resposta não é uma resposta.

Em código, o bug mora na confusão entre “não consegui saber” e “sei que não existe”:

# ❌ Fallback destrutivo: trata erro como "não existe" e AGE sobre isso
def sincronizar_carrinho(item_id):
    try:
        oferta = catalogo.get_oferta(item_id)   # serviço sobrecarregado
    except ServicoIndisponivel:
        oferta = None                            # ERRO: falha vira "sem oferta"
    if oferta is None:
        carrinho.remover(item_id)   # decisão destrutiva com base em incerteza
        # sob incidente do catálogo, MILHÕES de itens somem dos carrinhos

# ✅ Preserva o trabalho: na dúvida, não age destrutivamente
def sincronizar_carrinho(item_id):
    try:
        oferta = catalogo.get_oferta(item_id)
    except ServicoIndisponivel:
        # "não consegui consultar" ≠ "não existe": mantém o item como está
        return  # nenhuma ação destrutiva enquanto há incerteza
    if oferta is None:      # só age quando a resposta é uma CERTEZA
        carrinho.remover(item_id)

A diferença é entre um sistema que, na dúvida, destrói o trabalho do cliente, e um que, na dúvida, o preserva.

A retomada que derruba de novo

Um detalhe que quase ninguém considera: a bimodalidade também ataca na recuperação. Depois de uma falha, religar o sistema “de uma vez só” pode ser tão perigoso quanto a falha original. Um serviço que havia desativado uma camada de cache e depois a reativou instantaneamente para 100% do tráfego viu o cache ser incapaz de absorver a enxurrada súbita: timeouts, filas de retry dobrando o trabalho e a disponibilidade caindo novamente. A recuperação também é um modo — e a transição de volta ao normal precisa ser gradual (uma rampa de 20% em 20%, por exemplo), senão o próprio ato de recuperar vira um segundo incidente.

O retry em lote que multiplica a carga

Retentar é saudável para falhas transitórias e isoladas — mas retentar lotes inteiros quando só uma parte falhou transforma um soluço em avalanche. Considere um cliente que reenvia um batch completo de requisições a cada falha parcial: sob estresse, ele pode gerar dezenas de vezes o tráfego normal contra os componentes já degradados, impedindo justamente a recuperação. O modo de falha (retry agressivo de tudo) tem um perfil de carga radicalmente diferente do modo normal — bimodalidade clássica. A correção é retry granular (só o que de fato falhou), com backoff exponencial e teto de taxa.

O contraste aparece direto no código do cliente:

# ❌ Retry do lote inteiro: 1 falha reenvia os 100
def processar_lote(itens):
    while True:
        resultado = servico.enviar(itens)     # reenvia TUDO
        if resultado.ok:
            return
        time.sleep(1)   # sob falha parcial, martela o serviço com o lote cheio

# ✅ Retry granular: reenvia só o que falhou, com backoff + teto
def processar_lote(itens):
    pendentes = list(itens)
    espera = 0.1
    while pendentes:
        falhas = servico.enviar(pendentes).itens_com_falha   # só os que falharam
        if not falhas:
            return
        pendentes = falhas
        time.sleep(min(espera, TETO))   # backoff exponencial com teto
        espera *= 2

No primeiro caso, a carga sob falha é um múltiplo da carga normal. No segundo, ela tende a diminuir a cada ciclo — o oposto de uma avalanche.

Por que os Fallbacks falham?

Pense na seguinte metáfora. Um banco comprou um gerador de emergência e, todo mês, ligava-o brevemente para “testar” — o motor pegava, e todos ficavam tranquilos. No dia em que a energia realmente caiu, o gerador ligou e, quinze minutos depois, morreu: o teste mensal nunca o havia exercitado sob carga real e sustentada. É a metáfora perfeita do fallback: um caminho que parece funcionar nos testes superficiais, mas que só é cobrado de verdade no pior momento — e falha exatamente aí. Se um modo de emergência não roda continuamente sob condições reais, você não tem um plano de contingência; você tem uma suposição.

Latência e sobreposição de carga

Um dos maiores problemas com os fallbacks é que eles podem introduzir latência adicional. Quando um sistema passa para um modo de fallback, ele geralmente faz isso em resposta a uma falha ou uma condição de sobrecarga. No entanto, essa transição pode adicionar um tempo extra de processamento, especialmente se o fallback envolver consultas a componentes mais lentos, como um banco de dados em vez de um cache.

Além disso, como discutido anteriormente, a sobrecarga em um componente de fallback pode causar uma falha em cascata. Em vez de resolver o problema, o fallback pode ampliá-lo, resultando em uma interrupção mais ampla e mais severa.

Modos de operação raros e mal testados

Fallbacks são, por definição, modos de operação que não são usados regularmente. Isso significa que eles são menos testados, tanto em ambientes de desenvolvimento quanto em produção. Quando eles são ativados, é mais provável que ocorram falhas não previstas, o que pode levar a comportamentos inesperados.

Em um sistema distribuído, onde diferentes componentes podem estar espalhados por várias regiões geográficas e infraestruturas, a complexidade de testar e validar todos os cenários de fallback é enorme. Mesmo com testes abrangentes, há sempre o risco de cenários imprevisíveis ocorrerem em produção.

Falhas em cascata

Uma das falhas mais críticas associadas aos fallbacks é a falha em cascata. Isso ocorre quando o componente de fallback é sobrecarregado por um fluxo inesperado de tráfego ou falhas subsequentes, causando uma série de falhas que se propagam por todo o sistema.

Um exemplo clássico seria uma redistribuição imediata de partições depois da perda de um nó. Os nós restantes precisam atender mais tráfego e, ao mesmo tempo, copiar estado, reconstruir índices e aquecer memória. Se eles não tiverem folga para absorver os dois trabalhos juntos, a recuperação pode derrubar justamente os nós que deveriam estabilizar o sistema.

Complexidade de implementação

Implementar fallbacks muitas vezes requer adicionar lógica extra ao sistema, o que aumenta a complexidade do código e torna o sistema mais difícil de manter e evoluir. Essa complexidade adicional pode introduzir novos bugs e tornar o sistema mais propenso a falhas.

Além disso, a necessidade de manter e testar continuamente os modos de fallback adiciona uma carga operacional significativa, aumentando os custos e a dificuldade de gerenciar o sistema.

Há outra forma de pensar: O Princípio do Trabalho Constante

O princípio do trabalho constante(trabalho constante) baseia-se na ideia de que um sistema deve realizar a mesma quantidade de trabalho, independentemente da carga ou das condições de operação. Em vez de alternar entre os modos, o sistema opera de maneira uniforme, realizando operações consistentes em todas as situações. Isso elimina a necessidade de modos de fallback e reduz a complexidade e os riscos associados aos comportamentos bimodais.

Operação consistente

Ao adotar o princípio de trabalho constante, um sistema garante que a mesma quantidade de trabalho seja realizada, independentemente do número de solicitações ou da saúde dos componentes do sistema. Isso significa que o sistema não precisa alterar seu comportamento em resposta a condições adversas, tornando-o mais previsível e fácil de gerenciar.

O sistema de health checks do Route 53 foi projetado para realizar sempre a mesma quantidade de trabalho, independentemente do estado dos alvos ou do número de configurações ativas. Os health checkers enviam constantemente aos agregadores um conjunto de resultados de tamanho fixo (máximo suportado), preenchendo com entradas fictícias quando há poucos health checks configurados. Isso elimina qualquer variação de carga de rede ou processamento à medida que clientes adicionam novos alvos. Da mesma forma, os agregadores enviam periodicamente uma tabela de tamanho fixo aos servidores DNS, que a armazenam em memória — sempre o mesmo volume de dados, sempre a mesma operação.

O resultado mais poderoso desse design é que falhas em massa não alteram o comportamento do sistema. Mesmo que uma Availability Zone inteira perca energia e milhares de health checks falhem simultaneamente, os health checkers, agregadores e servidores DNS continuam executando exatamente o mesmo trabalho que já faziam antes. Os servidores DNS, ao receberem uma consulta, sempre verificam todas as respostas possíveis cruzando com a tabela em memória — não há mudança de modo, não há explosão de atualizações DNS, não há aumento de tempo de processamento. O código executa as mesmas ações sempre; a única diferença é quais respostas são selecionadas como resultado. Esse padrão de trabalho constante torna o sistema extremamente confiável justamente nos momentos mais críticos.

Redução de variabilidade

Um dos maiores desafios em sistemas distribuídos é lidar com a variabilidade na carga e nas condições operacionais. A variabilidade pode causar flutuações no desempenho e aumentar a probabilidade de falhas. Ao operar de maneira constante, um sistema elimina a variabilidade, mantendo um desempenho estável e previsível.

No caso do Route 53, mesmo que centenas ou milhares de endpoints falhem simultaneamente, o sistema realiza o mesmo trabalho, sem aumentar o tempo de processamento ou sobrecarregar os recursos. Isso elimina a possibilidade de uma falha em cascata, onde um componente falha e sobrecarrega outros, levando a um colapso do sistema.

Anti-fragilidade

Sistemas baseados em trabalho constante podem se tornar anti-frágeis, ou seja, podem melhorar seu desempenho sob condições de estresse. Por exemplo, em um sistema onde menos trabalho é necessário sob alta carga (como a redução da carga em urnas de café à medida que o café é servido), o sistema pode se tornar mais eficiente em momentos de maior estresse.

Outro exemplo de trabalho constante é encontrado no AWS Hyperplane, o sistema por trás de componentes críticos como os Network Load Balancers. Quando um cliente faz uma alteração em um load balancer, o Hyperplane processa essas alterações armazenando as configurações em arquivos no Amazon S3.

Esses arquivos são então carregados e aplicados periodicamente por todos os nós do Hyperplane, independentemente de haver alterações ou não. Isso significa que o sistema está sempre processando a quantidade máxima de configurações, independentemente do número real de mudanças. Essa abordagem evita picos de carga e garante que o sistema continue operando de maneira eficiente e previsível, mesmo sob condições extremas.

Além disso, como o Hyperplane é altamente redundante, a carga de trabalho é distribuída uniformemente entre os nós. Se um nó falhar, a carga de trabalho geral diminui, em vez de aumentar, garantindo que o sistema continue funcionando sem interrupções.

Simples de implementar e manter

Uma das maiores vantagens do trabalho constante é a simplicidade. Como o sistema opera da mesma maneira em todas as condições, a lógica é mais simples e direta. Isso não só torna o sistema mais fácil de implementar, mas também reduz a necessidade de testes complexos e a probabilidade de introduzir novos bugs.

Além disso, a simplicidade torna o sistema mais fácil de manter a longo prazo. Equipes de engenharia podem entender rapidamente como o sistema opera, e novas funcionalidades podem ser adicionadas sem o risco de quebrar a lógica existente.

O trabalho constante produz estabilidade estática

Vale nomear um conceito que anda de mãos dadas com o trabalho constante: a estabilidade estática (static stability). Um sistema é estaticamente estável quando continua operando corretamente durante uma falha sem mudar o seu estado — sem tomar decisões novas, sem acionar caminhos de recuperação, sem depender de um plano de controle para “consertar” as coisas no calor do momento quando suas dependências falham.

A relação entre os dois é direta: o trabalho constante é o mecanismo que produz estabilidade estática. O Route 53 é estaticamente estável justamente porque faz trabalho constante — quando uma Zona de Disponibilidade cai, ele não precisa reagir, recalcular ou mudar de modo, porque já estava verificando todos os endpoints o tempo todo. A perda da AZ não representa um evento novo a ser tratado; representa apenas menos respostas positivas dentro do mesmo trabalho que já era feito. É por isso que os dois princípios aparecem sempre juntos na literatura de confiabilidade da AWS: trabalho constante é o como, static stability é o resultado.

Failover sobre fallback

Aqui é preciso separar dois conceitos que costumam ser confundidos, e essa confusão é justamente a raiz de muitos comportamentos bimodais. Fallback é quando o sistema, diante de uma falha, passa a fazer um trabalho diferente — troca de modo, muda o caminho de execução, aciona uma lógica que normalmente fica adormecida. Failover é quando o sistema continua fazendo exatamente o mesmo trabalho, apenas em um recurso saudável e idêntico ao que falhou. A diferença parece sutil, mas é ela que decide se você está aumentando ou reduzindo a resiliência.

O fallback é bimodal por definição: ele existe para criar um segundo modo de operação. O failover, quando bem feito, é o oposto — ele preserva a uniformidade. Se você tem três réplicas idênticas de um serviço e uma cai, o failover redireciona o tráfego para as outras duas sem mudar a natureza da operação. Nenhum código novo é acionado, nenhum caminho raro é percorrido, nenhuma lógica “de emergência” que ninguém testou há seis meses entra em cena. O trabalho é o mesmo; muda apenas onde ele acontece.

O ponto central é este: prefira failover para recursos redundantes e idênticos, e desconfie de qualquer fallback que troque a natureza do trabalho. Um failover para uma réplica read-only do banco é seguro porque a réplica faz o mesmo que o primário fazia. Já um fallback que, diante da falha do cache, começa a martelar o banco de dados com o padrão de acesso do cache não é redundância — é um segundo modo de operação, com perfil de carga diferente, que ninguém dimensionou. É por isso que failover sobre fallback é quase sempre a escolha mais resiliente: você elimina o modo bimodal em vez de criá-lo.

Veja a diferença na prática. Primeiro, o fallback bimodal — o padrão perigoso:

# ❌ FALLBACK: sob falha, muda a NATUREZA do trabalho
def get_produto(produto_id):
    try:
        return cache.get(produto_id)          # modo normal
    except CacheIndisponivel:
        # modo de emergência: caminho raro, mal testado,
        # com perfil de carga totalmente diferente.
        # Se o cache caiu inteiro, TODAS as chamadas caem aqui
        # e o banco — que nunca viu esse volume — desaba.
        return banco.query(produto_id)         # modo fallback

Agora o failover — mesmo trabalho, recurso saudável:

# ✅ FAILOVER: sob falha, o MESMO trabalho em outro nó idêntico
def get_produto(produto_id):
    # a lista contém réplicas idênticas do MESMO cache distribuído.
    # trocar de nó não muda a natureza da operação nem o perfil de carga.
    for no in replicas_cache_saudaveis():
        try:
            return no.get(produto_id)
        except NoIndisponivel:
            continue  # tenta a próxima réplica — trabalho idêntico
    raise ServicoIndisponivel()  # falha explícita, sem modo oculto

No primeiro caso, a falha do cache transforma o comportamento do sistema. No segundo, ela apenas muda onde o mesmo trabalho é feito — não existe um segundo modo esperando para dar errado.

Como DynamoDB usa o princípio do trabalho constante

Vimos que o grande problema do cache é o comportamento bimodal do cache miss: enquanto há acerto, o banco está protegido; quando o cache esvazia, todo o tráfego desaba sobre o banco de uma vez. A pergunta certa não é “como faço um fallback melhor para o banco?”, e sim “como faço o cache parar de ser bimodal?”.

A resposta que o DynamoDB adota internamente é tratar o cache como uma estrutura que faz trabalho constante, e não como uma otimização oportunista. Em vez de popular o cache sob demanda (o que cria o padrão frágil de “quente quando cheio, catastrófico quando vazio”), você mantém o conjunto de dados relevante — tabelas de roteamento, metadados de partição, informação de membership — sempre carregado e sendo atualizado em cadência fixa, independentemente de haver requisição ou não. O cache nunca “esvazia sob carga” porque ele não depende do tráfego para se preencher: ele é atualizado o tempo todo, no mesmo ritmo, esteja o sistema ocioso ou no pico.

O efeito prático é que o cache miss deixa de ser um evento de carga. Não existe mais o momento em que o banco recebe uma enxurrada de consultas porque o cache expirou — o dado já está lá, sempre, porque mantê-lo atualizado é o trabalho normal do sistema, não uma reação a uma falha. Você paga o custo de manter tudo carregado o tempo inteiro, mas em troca elimina a cliff de latência e a falha em cascata. É a mesma filosofia do Route 53 verificando todos os endpoints: fazer sempre o trabalho máximo para que a falha não represente um salto de carga.

Na prática, a diferença está em quem alimenta o cache e quando. No padrão bimodal, é o tráfego do usuário que popula o cache sob demanda; no padrão de trabalho constante, um processo em segundo plano recarrega o conjunto inteiro em cadência fixa:

# ❌ Cache bimodal: populado sob demanda (lazy)
def get_rota(chave):
    valor = cache.get(chave)
    if valor is None:              # cache miss → vai ao banco
        valor = banco.get(chave)   # sob falha do cache, TODOS caem aqui
        cache.set(chave, valor)
    return valor

# ✅ Cache com trabalho constante: sempre pré-carregado, atualização fixa
class CacheConstante:
    def __init__(self):
        self._dados = {}
        threading.Thread(target=self._recarregar_sempre, daemon=True).start()

    def _recarregar_sempre(self):
        # trabalho CONSTANTE: recarrega o dataset inteiro a cada 5s,
        # haja tráfego ou não. O cache nunca "esvazia sob carga".
        while True:
            self._dados = banco.carregar_tabela_completa()  # volume fixo e limitado
            time.sleep(5)

    def get_rota(self, chave):
        return self._dados.get(chave)   # nunca vai ao banco no caminho quente

O cache miss deixa de existir como evento de carga: o dado já está sempre lá, e a falha nunca vira um salto de tráfego para o banco.

Há ainda uma armadilha mais sutil: usar o cache como fallback não protege contra o modo de falha mais comum. Colocar um cache “na frente” de um serviço como rede de segurança dá uma falsa sensação de resiliência. Se o cliente consulta o cache antes da origem e a origem passa a responder com dados incorretos — não indisponível, mas errada — o cache apenas memoriza e propaga o erro (um efeito de cache poisoning). Cache-como-fallback só cobre o caso de indisponibilidade total, que costuma ser o modo de falha mais raro; ele não protege contra respostas erradas, que são o modo mais comum. Antes de adotar cache como proteção, pergunte-se contra qual modo de falha ele realmente protege.

O detalhe fatal costuma ser a ordem da consulta:

# ❌ Cache consultado ANTES da origem: memoriza e propaga respostas erradas
def resolver(chave):
    if chave in cache:
        return cache[chave]          # se a origem já gravou lixo aqui, propaga
    valor = origem.get(chave)        # origem pode responder INCORRETAMENTE
    cache[chave] = valor             # cache envenenado com o erro
    return valor

# ✅ Cache como fallback APENAS de indisponibilidade, nunca de correção
def resolver(chave):
    try:
        valor = origem.get(chave)    # a origem é sempre a fonte da verdade
        cache[chave] = valor         # cache só reflete respostas válidas
        return valor
    except OrigemIndisponivel:
        return cache.get(chave)      # fallback só quando NÃO há resposta

No primeiro caso o cache protege contra o modo raro (indisponibilidade) mas amplifica o modo comum (resposta errada). No segundo, ele cobre só aquilo para o qual um cache realmente serve.

Gerenciamento de configuração

O gerenciamento de configuração é um dos lugares onde o comportamento bimodal se esconde com mais facilidade — e o padrão do Hyperplane que vimos antes é justamente o antídoto, aplicado a um domínio diferente. A tentação natural é distribuir configuração de forma incremental: quando algo muda, envie apenas o delta para os nós que precisam saber. Parece eficiente, mas cria dois modos de operação — “sem mudanças, tráfego zero de configuração” e “muitas mudanças ao mesmo tempo, avalanche de deltas” — e é exatamente no segundo modo, durante um evento de grande mudança, que o mecanismo de distribuição desaba.

A abordagem de trabalho constante inverte a lógica: distribua sempre a configuração completa, em cadência fixa, independentemente de ter havido mudança. Cada nó baixa periodicamente o snapshot inteiro — a lista completa de rotas, regras, endpoints — e aplica tudo, mesmo que 99% seja idêntico ao que já tinha. O volume de trabalho de distribuição é constante e previsível: é o mesmo num dia calmo e num dia em que milhares de configurações mudaram de uma vez.

Isso traz um benefício adicional silencioso: a configuração passa a ser auto-corretiva. Como o estado completo é reaplicado o tempo todo, qualquer divergência — um nó que perdeu uma atualização, um estado corrompido, um deploy parcial — é curada no próximo ciclo, sem intervenção. Você troca a “eficiência” de mandar só o delta pela robustez de um sistema que converge sozinho para o estado correto e nunca tem um pico de trabalho de configuração.

Em código, o contraste fica claro no que cada nó faz a cada ciclo:

# ❌ Delta incremental: bimodal — reage a cada mudança
def ao_mudar_config(evento_delta):
    # num deploy em massa, milhares desses eventos chegam de uma vez.
    # o volume de trabalho é imprevisível e explode no pior momento.
    aplicar_mudanca(evento_delta)

# ✅ Snapshot completo em cadência fixa: trabalho constante
def loop_de_configuracao():
    while True:
        snapshot = baixar_config_completa()   # SEMPRE o estado inteiro
        aplicar_config(snapshot)               # reaplica tudo, mesmo sem mudança
        # trabalho idêntico num dia calmo ou num dia de mil mudanças.
        # bônus: qualquer divergência é auto-corrigida no próximo ciclo.
        time.sleep(10)

O trabalho por ciclo é sempre o mesmo — e, como o estado completo é reaplicado continuamente, o sistema se auto-corrige sem nunca precisar de um caminho especial de reconciliação.

Backup e restore contínuos

Backup é o exemplo mais clássico de trabalho eventual — e, portanto, uma fábrica de comportamento bimodal. O modelo tradicional roda um job pesado uma vez por dia ou por semana: durante 23 horas o sistema não faz backup nenhum, e por uma hora ele consome I/O, CPU e banda de forma intensa. Se esse pico coincidir com um pico de carga real, os dois se somam e derrubam o sistema. Pior: o restore só é exercitado no dia do desastre — é o caminho de fallback definitivo, raramente testado, acionado no pior momento possível.

A alternativa de trabalho constante é transformar backup e restore em fluxo contínuo em vez de eventos. Em vez de um snapshot monolítico periódico, o sistema faz backup incremental e contínuo — capturando mudanças à medida que elas acontecem (por exemplo, via streaming do log de transações). O trabalho de backup deixa de ter picos: ele é uma corrente fina e constante, sempre no mesmo ritmo, diluída ao longo do tempo em vez de concentrada numa janela. É o que o próprio DynamoDB oferece com point-in-time recovery: não existe “a hora do backup”, porque o backup é o tempo todo.

E o restore? A mesma lógica se aplica: quanto mais frequentemente você exercita a restauração — idealmente de forma contínua e automatizada, validando backups o tempo todo — menos ele é um modo raro e assustador. Um restore que roda todo dia como parte da operação normal não é um fallback; é trabalho constante. Você descobre que o backup está corrompido num teste de terça-feira, não durante o incêndio.

Filas, backlogs e trabalho constante

Filas merecem uma discussão própria porque são uma das abstrações mais úteis e, ao mesmo tempo, mais traiçoeiras em sistemas distribuídos. Uma fila aumenta durabilidade: se o consumidor falha, a mensagem continua lá. Ela desacopla produtor e consumidor. Ela suaviza picos curtos. Tudo isso é verdade. Mas existe uma frase que precisa ficar martelando na sua cabeça: fila não elimina trabalho; fila desloca trabalho no tempo.

Quando o sistema está saudável, esse deslocamento parece inofensivo. O produtor publica, o consumidor processa, a fila fica pequena e a latência de ponta a ponta continua baixa. Mas quando o consumidor fica lento, uma dependência começa a falhar ou a taxa de chegada passa a taxa de processamento, a fila muda de natureza. Ela deixa de ser um amortecedor e vira uma dívida operacional crescendo em silêncio.

O comportamento bimodal aparece na recuperação. Depois de uma hora de problema, o sistema volta e tenta “colocar a casa em ordem”: aumenta a concorrência, sobe mais workers, reduz delays, retenta mensagens antigas e tenta drenar o backlog o mais rápido possível. Parece a atitude correta, mas pode ser exatamente o segundo incidente. O banco, a API downstream, o serviço de pagamento, o storage ou qualquer dependência que participa do processamento passa a receber uma carga que nunca receberia no modo normal.

O trabalho constante aplicado a filas não significa processar tudo sempre, porque o volume de mensagens pode crescer sem limite. Esse é um ponto importante: filas normalmente vivem no data plane, e data planes não têm o mesmo teto previsível de um conjunto de health checks ou de uma tabela de configuração. Então a pergunta muda. Não é “como faço o trabalho máximo o tempo todo?”, e sim: como mantenho constante e segura a taxa de trabalho executada, mesmo quando a fila cresce?

O anti-padrão é deixar o tamanho do backlog controlar diretamente a quantidade de trabalho executado:

# ❌ Drenagem bimodal: backlog decide a agressividade do sistema
def consumir_fila():
    while True:
        backlog = fila.tamanho()

        if backlog > 100_000:
            concorrencia = 2_000       # muda de modo sob estresse
            delay_retry = 0            # retries imediatos
        else:
            concorrencia = 100
            delay_retry = 1

        mensagens = fila.receber(max_messages=concorrencia)
        for mensagem in mensagens:
            try:
                processar(mensagem)    # chama banco, APIs e dependências
                fila.apagar(mensagem)
            except Exception:
                fila.reenfileirar(mensagem, delay=delay_retry)

Esse código parece elástico, mas é bimodal. Em modo normal, o sistema consome numa taxa confortável. Sob backlog, ele muda a própria personalidade: mais concorrência, retries mais agressivos, mais pressão nas dependências e maior chance de transformar recuperação em avalanche. O backlog passa a dirigir o sistema.

Um desenho mais resiliente faz o oposto: mantém uma taxa segura de consumo, isola workloads, trata mensagens antigas como outra classe de trabalho e aplica backpressure quando as dependências estão degradadas.

# ✅ Trabalho constante: taxa segura, isolamento e dívida controlada
def consumir_fila():
    limite_global = RateLimiter(500)          # teto conhecido por segundo
    limite_por_cliente = RateLimiterPorChave(50)

    while True:
        mensagem = fila.receber()
        cliente = mensagem.cliente_id

        if mensagem.idade > timedelta(minutes=15):
            fila_backlog.enviar(mensagem)     # dívida separada do tempo real
            fila.apagar(mensagem)
            continue

        if not dependencias_saudaveis():
            fila.reenfileirar(mensagem, delay=com_jitter(30))
            continue

        if not limite_global.permitir() or not limite_por_cliente.permitir(cliente):
            fila.reenfileirar(mensagem, delay=com_jitter(5))
            continue

        try:
            processar(mensagem)
            fila.apagar(mensagem)
        except ErroTransitorio:
            fila.reenfileirar(mensagem, delay=backoff_com_jitter(mensagem.tentativas))
        except ErroDefinitivo:
            dlq.enviar(mensagem)
            fila.apagar(mensagem)

Perceba a diferença: a fila pode estar enorme, mas o sistema não entra em modo de pânico. O trabalho executado por segundo continua dentro de um envelope conhecido. Mensagens antigas não competem com o caminho quente. Um cliente barulhento não consome a capacidade dos outros. Dependências lentas não recebem uma enxurrada justamente quando estão tentando se recuperar. Isso não torna o backlog irrelevante, mas transforma o backlog em algo gerenciável.

Em sistemas em tempo real, isso costuma levar a uma decisão que parece contraintuitiva: mensagens novas podem ser mais valiosas que mensagens antigas. Se uma mensagem ficou parada por tempo demais, talvez ela deva ir para uma fila de backlog, expirar por TTL ou ser substituída por uma sincronização completa posterior. Um evento de “produto atualizado” de duas horas atrás pode não valer mais nada se existe uma varredura periódica que reconcilia o estado inteiro. De novo, resiliência não é fazer todo trabalho custe o que custar; é preservar a utilidade do sistema sob falha.

O aprendizado é simples e duro: se a recuperação de uma fila exige que o sistema trabalhe dez vezes mais do que trabalha normalmente, você não tem trabalho constante. Você tem uma bomba de atraso. O desenho resiliente é aquele em que backlog, retry e drenagem não mudam a natureza do sistema. A fila pode crescer. A dívida pode existir. Mas o ritmo de pagamento dessa dívida precisa ser seguro, previsível e compatível com as dependências que sustentam o processamento.

Uniformidade de APIs e logs

Por fim, um lugar onde o comportamento bimodal se infiltra quase sem ninguém perceber: o tamanho e a forma do que sua aplicação produz sob falha. Lá no começo do artigo eu citei o caso dos logs que passam de 1kb no modo normal para 10kb quando algo dá errado. Esse é um bimodalismo traiçoeiro, porque ele aumenta a carga exatamente quando o sistema está mais frágil. No instante em que tudo começa a falhar — e você mais precisa de I/O disponível — a aplicação decide despejar dez vezes mais log, competindo por disco e rede justamente na hora errada, transformando um incidente contornável num colapso.

O mesmo vale para APIs: uma resposta que normalmente carrega um payload enxuto, mas que sob erro passa a incluir stack traces enormes, objetos de diagnóstico e retries embutidos, muda o perfil de banda e de processamento no pior momento. É a mesma armadilha do fallback, só que na camada do protocolo.

O princípio de trabalho constante aplicado aqui é buscar uniformidade de trabalho por requisição, independentemente do resultado. Log de erro e log de sucesso devem ter ordens de grandeza parecidas — se você precisa de mais detalhe para depurar, use amostragem ou níveis de log ajustáveis sob demanda, em vez de um salto automático de volume no pior instante. Respostas de erro devem ter tamanho previsível, comparável às de sucesso. A meta é que a falha não seja mais cara, em recursos, do que o sucesso — porque no momento em que a falha custa mais, ela vira combustível para a cascata.

O anti-padrão costuma se esconder num detalhe inocente do tratamento de erro:

# ❌ Log bimodal: a falha custa 10× mais I/O que o sucesso
def tratar_requisicao(req):
    try:
        resultado = processar(req)
        log.info("ok")                      # ~1kb
        return resultado
    except Exception as e:
        # sob incidente, MILHÕES dessas linhas gigantes competem
        # por disco e rede — exatamente quando o I/O é escasso.
        log.error(f"falha: {traceback.format_exc()} "
                  f"contexto={dump_completo_do_estado(req)}")  # ~10kb
        raise

# ✅ Log uniforme: erro e sucesso têm ordem de grandeza parecida
def tratar_requisicao(req):
    try:
        resultado = processar(req)
        log.info("ok id=%s", req.id)         # ~1kb
        return resultado
    except Exception as e:
        # linha enxuta e de tamanho previsível; o detalhe fica
        # atrás de amostragem, acionável só quando necessário.
        log.error("falha id=%s tipo=%s", req.id, type(e).__name__)  # ~1kb
        if amostrar(taxa=0.01):              # 1% com stack completo
            log.debug("trace id=%s %s", req.id, traceback.format_exc())
        raise

A meta é simples: a falha não pode custar mais recursos que o sucesso, senão o próprio tratamento de erro vira o gatilho do colapso.

Quando o trabalho constante não é a resposta

Na nossa área de atuação, não existe o certo e o errado, tudo “depende”, tem seus prós e constras. Seria desonesto vender o trabalho constante como uma bala de prata — ele tem um custo real, e reconhecê-lo é o que separa uma decisão de engenharia madura de uma moda cega.

Você paga pelo pior caso o tempo todo

A essência do trabalho constante é dimensionar para o máximo e operar sempre nesse nível, mesmo quando a carga real é baixa. Isso significa desperdício deliberado de recursos: CPU, memória, banda e, no fim, dinheiro. Num sistema com carga muito baixa ou muito esporádica, manter o motor sempre no talo pode não se justificar economicamente.

Ele pressupõe um volume de trabalho limitado e conhecido

O padrão funciona lindamente quando o “trabalho total” tem um teto previsível: um número finito de health checks, uma tabela de configuração que cabe em memória, um conjunto de rotas que não cresce sem limite. Quando o volume de dados a processar pode crescer de forma ilimitada ou tem cardinalidade muito alta, “fazer sempre o trabalho máximo” deixa de ser constante e vira simplesmente caro e inviável — você não vai pré-carregar um dataset de terabytes “só por garantia”.

Como decidir então?

Aplique trabalho constante onde o trabalho é limitado, o custo do pior caso é aceitável e a previsibilidade sob falha vale mais que a economia de recursos em regime normal — tipicamente em planos de controle, roteamento, health checking e distribuição de configuração. Para data planes com volume ilimitado, como filas de eventos, prefira outras ferramentas (backpressure, isolamento por células, limites por workload, TTL, DLQ e degradação que preserva uniformidade). Nesses casos, o trabalho constante não é “processar tudo sempre”; é manter uma taxa segura e previsível de processamento. O objetivo nunca é “fazer trabalho constante a qualquer custo” — é eliminar a bimodalidade, e o trabalho constante é uma das formas de fazer isso, não a única.

Fallback vs. trabalho constante

Dimensão	Fallback (bimodal)	trabalho constante (unimodal)
Modos de operação	Dois: normal e emergência	Um só, sempre igual
Comportamento sob falha	Muda de caminho, aciona lógica rara	Não muda nada — mesmo trabalho
Carga no momento da falha	Salta (pico bem quando o sistema está frágil)	Constante, sem picos
Testabilidade	Ruim: modo raro, mal exercitado	Ótima: o único modo roda o tempo todo
Risco de falha em cascata	Alto: o fallback vira o vetor do colapso	Baixo: sem transição, sem amplificação
Complexidade de código	Maior: lógica extra de detecção e troca	Menor: um caminho, previsível
Custo de recursos em regime normal	Menor: só gasta o necessário	Maior: paga o pior caso sempre
Melhor aplicação	Evitar quando possível; ok se preservar uniformidade	Planos de controle, roteamento, config, health check

Conclusão

Se você tirar uma só ideia deste post, que seja esta: projete sistemas que fazem a mesma quantidade de trabalho o tempo todo — inclusive quando falham. A intuição de criar um “modo de emergência” para lidar com o pior caso é sedutora, mas é justamente ela que introduz o comportamento bimodal: um segundo modo, raro, mal testado, que é acionado no instante de maior estresse e que amplifica a falha em vez de contê-la. Fallbacks, na maioria das vezes, atrapalham mais do que ajudam.

O trabalho constante inverte a lógica. Em vez de reagir à falha mudando de comportamento, o sistema nunca muda de comportamento — ele já está sempre fazendo o trabalho máximo. Não há transição para dar errado, não há modo escondido, não há pico de carga na hora errada. Route 53 verificando todos os endpoints o tempo todo, o Hyperplane reaplicando a configuração inteira a cada ciclo, um cache que se atualiza sozinho independentemente do tráfego: todos respondem àquela pergunta do início — quando algo falha, eles fazem a mesma coisa de sempre. E é por isso que aguentam.

Isso não é grátis, e eu não quero te vender uma bala de prata: você paga pelo pior caso o tempo todo, e nem todo problema cabe nesse molde. Mas, para os caminhos críticos do seu sistema — roteamento, health check, distribuição de configuração, controle, sistemas transacionais ou de missão crítica —, trocar a esperteza reativa pela previsibilidade constante é uma das decisões de arquitetura que mais aumentam a resiliência com menos complexidade.

No fim, não significa que você não deve utilizar fallbacks, caches ou as abordagens aqui citadas ou até evidênciadas como arriscadas, mas é sobre conhecer seus riscos e assumir de forma consciente.

Referências

• https://medium.com/@linoyzaga/scaling-applications-with-constant-work-pattern-f253176b3146
• https://aws.amazon.com/blogs/architecture/doing-constant-work-to-avoid-failures/
• https://news.ycombinator.com/item?id=34103426
• https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_prevent_interaction_failure_constant_work.html
• https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_static_stability.html
• https://aws.amazon.com/builders-library/challenges-with-distributed-systems/
• https://a-nickels-worth.dev/posts/modesharm/
• https://aws.amazon.com/builders-library/minimizing-correlated-failures-in-distributed-systems/
• https://aws.amazon.com/builders-library/avoiding-overload-in-distributed-systems-by-putting-the-smaller-service-in-control/
• https://aws.amazon.com/builders-library/reliability-and-constant-work/?did=ba_card&trk=ba_card
• https://aws.amazon.com/pt/builders-library/avoiding-insurmountable-queue-backlogs/
• https://www.youtube.com/watch?v=4GKXx9vIqsk&t=646s
• https://builder.aws.com/content/3EuRcgkTP1MI0c7zM8W6HL3WIqA/avoiding-insurmountable-queue-backlogs