Coinbase (2026): o control plane do AWS MSK que travou o trading

Na manhã de 7 de maio de 2026, a Coinbase começou a observar degradação severa em seus serviços de trading. Não foi uma queda abrupta, foi uma erosão progressiva que tornou o diagnóstico inicial confuso. Os serviços de fee calculation, quoting e execução de ordens começaram a falhar ou a travar em espera por respostas que nunca chegavam. A causa não era óbvia: os brokers Kafka estavam respondendo, as conexões de rede estavam ativas, e os produtores conseguiam publicar mensagens em algumas partições.

O problema estava em um nível abaixo do que as equipes de engenharia da Coinbase podiam observar diretamente: o control plane do Amazon MSK. Esse componente, operado exclusivamente pela AWS, é responsável por orquestrar operações de manutenção, rebalanceamento de partições, e, criticamente, a reeleição de líderes de partição quando um broker líder fica indisponível ou precisa ser substituído.

Um defeito nesse control plane colocou dois clusters MSK de produção em um estado chamado internamente de 'healing': um estado de manutenção do qual eles não conseguiam sair. Nesse estado, o MSK não conseguia completar a reeleição de líderes para as partições afetadas. O resultado prático: partições sem líder ativo. Produtores que tentavam escrever nessas partições recebiam erros ou ficavam bloqueados. Consumidores não conseguiam avançar seus offsets. Os serviços downstream, que dependem de mensagens nesses tópicos para calcular fees, gerar quotes e processar ordens, pararam de funcionar de forma coerente.

O que torna esse incidente particularmente insidioso é o modo de falha silencioso. Não houve um crash explícito, nenhum erro de conexão óbvio, nenhum alerta de 'cluster down'. Os clusters tecnicamente existiam e respondiam a algumas operações. A falha estava em uma operação específica de coordenação, reeleição de líder, que o sistema gerenciado deveria executar automaticamente e não executou. Esse tipo de falha parcial é o mais difícil de detectar e diagnosticar, especialmente quando a camada defeituosa está fora do seu controle operacional.

O impacto desse incidente foi desproporcionalmente amplo para uma falha que, tecnicamente, afetou 'apenas' o mecanismo de reeleição de líderes de partição em dois clusters Kafka. Para entender por quê, é preciso entender o papel arquitetural que o Kafka desempenha na Coinbase.

Em arquiteturas event-driven financeiras, o Kafka não é apenas um sistema de mensageria, é o backbone de coordenação entre serviços. Os serviços de fee calculation precisam publicar e consumir eventos para calcular taxas em tempo real. O quoting service depende de streams de dados de mercado e de estado interno para gerar cotações precisas. A execução de ordens é um pipeline de eventos sequenciais onde cada etapa depende da anterior ter sido confirmada via Kafka. Quando as partições responsáveis por esses fluxos ficam sem líder, não há degradação gradual, há parada.

O segundo fator que amplificou o blast radius foi a ausência de circuit breakers e fallbacks efetivos nos serviços que dependiam dessas partições. Em vez de falhar rapidamente e comunicar o estado de indisponibilidade para os clientes, os serviços ficaram em estado de espera, produtores bloqueados aguardando confirmação de escrita, consumidores parados aguardando mensagens que não chegavam. Esse comportamento de hang em vez de fail-fast é particularmente danoso: ele consome recursos (threads, conexões, memória), propaga a indisponibilidade para serviços upstream que aguardam resposta, e torna o diagnóstico mais difícil porque o sistema parece 'ocupado' em vez de 'quebrado'.

O terceiro fator foi a concentração de dependência: dois clusters MSK, ambos afetados pelo mesmo defeito no control plane, cobrindo os tópicos críticos de trading. Não havia redundância de caminho, se os clusters estavam em estado 'healing', os serviços que dependiam deles simplesmente paravam. A arquitetura não tinha um mecanismo de degradação graciosa para o cenário específico de 'Kafka disponível mas sem líderes de partição'.

A remediação imediata foi necessariamente dependente da AWS: a Coinbase não tem acesso ao control plane do MSK, então a resolução exigiu que a AWS identificasse e corrigisse o defeito internamente. Isso por si só é uma lição arquitetural importante, quando seu plano de recuperação depende de um terceiro agir, seu MTTR está fora do seu controle.

No post-mortem, a Coinbase identificou várias linhas de ação para evitar que um incidente similar tenha o mesmo impacto:

Observabilidade de saúde de partição e líder. O incidente durou mais do que deveria em parte porque os dashboards existentes não tinham visibilidade granular sobre o estado de líderes de partição. Métricas como UnderReplicatedPartitions, OfflinePartitionsCount, e ActiveControllerCount são métricas padrão do Kafka que deveriam estar em alertas de primeiro nível. A ausência de líderes em partições específicas deveria gerar alerta imediato, não ser descoberta durante diagnóstico manual.

Timeouts e circuit breakers em produtores e consumidores Kafka. Produtores que ficam bloqueados indefinidamente esperando confirmação de escrita em uma partição sem líder são um anti-pattern. Configurações como request.timeout.ms, delivery.timeout.ms e max.block.ms precisam ser calibradas para garantir fail-fast. Do lado do consumidor, ausência de progresso de offset por um período definido deve disparar alertas e, idealmente, acionar lógica de circuit breaker nos serviços dependentes.

Estratégia de degradação graciosa para falhas de Kafka. Para serviços críticos como quoting e fee calculation, a questão 'o que fazemos quando o Kafka está indisponível?' precisa ter uma resposta arquitetural explícita. Isso pode incluir: fallback para cálculo síncrono direto, rejeição rápida com mensagem de erro clara para o cliente, ou modo de operação degradado com funcionalidade reduzida. O pior cenário, que é o que aconteceu, é não ter nenhuma dessas respostas e deixar os serviços em estado de hang.

Redução da dependência de serviço gerenciado como ponto único de coordenação. Isso é o mais difícil e o mais importante. Não estou dizendo para abandonar o MSK, serviços gerenciados têm valor real. Mas a arquitetura precisa reconhecer que qualquer serviço gerenciado pode falhar de formas que você não controla e não pode remediar diretamente. Isso significa: múltiplos clusters com tópicos críticos replicados, capacidade de roteamento entre clusters, e testes regulares de failover que incluam o cenário de 'cluster em estado de manutenção irrecuperável'.