# Coinbase (2026): o control plane do AWS MSK que travou o trading Em 7 de maio de 2026, um defeito no control plane do Amazon MSK impediu a reeleição automática de líderes de partição em dois clusters Kafka gerenciados da Coinbase, bloqueando silenciosamente os serviços de fee, quoting e execução de trades por horas. O incidente expõe os riscos ocultos de depender de serviços gerenciados como ponto único de coordenação — e a necessidade crítica de observabilidade profunda em infraestrutura que você não opera. - URL: https://fernando.moretes.com/studies/coinbase-aws-msk-2026 - Markdown: https://fernando.moretes.com/studies/coinbase-aws-msk-2026/study.md?lang=pt - Type: Post-mortem - Company: Coinbase - Domain: Dados/Resiliência - Date: 2026-05-07 - Tags: postmortem, kafka, aws-msk, resilience, coinbase, event-driven, observability, managed-services - Reading time: 11 min --- ## Ficha do Incidente - **Empresa:** Coinbase - **Data:** 7 de maio de 2026 - **Duração total do impacto:** Várias horas (degradação severa seguida de recuperação gradual) - **Serviço afetado:** Amazon MSK (Kafka gerenciado) — dois clusters de produção - **Impacto no negócio:** Quase todo o trading da Coinbase interrompido: serviços de fee, quoting e execução de ordens bloqueados - **Modo de falha:** Falha silenciosa — clusters presos em estado 'healing', sem reeleição automática de líder de partição - **Causa raiz:** Defeito no control plane do AWS MSK que bloqueou a reeleição de líderes Kafka - **Stack relevante:** AWS MSK (Kafka gerenciado), serviços internos de fee/quoting/trades, AWS (região não divulgada) - **Classificação:** Incidente de Severidade 1 — impacto crítico em receita e clientes Kafka não caiu. Os brokers estavam de pé. As métricas de saúde do cluster pareciam razoáveis. E ainda assim, quase todo o trading da Coinbase parou — porque o control plane do Amazon MSK, a camada que a Coinbase não opera e não pode depurar diretamente, entrou em um estado defeituoso que impediu silenciosamente a reeleição de líderes de partição. Este é o tipo de falha que não aparece nos seus dashboards de aplicação até que seja tarde demais: infraestrutura gerenciada que para de funcionar sem dizer por quê. ## O que aconteceu 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. ## Linha do Tempo 1. **T+0 — Início do evento no MSK** — Um defeito no control plane do Amazon MSK começa a afetar dois clusters Kafka de produção da Coinbase. Os clusters entram no estado 'healing'. Reeleição de líderes de partição é bloqueada silenciosamente. 2. **T+alguns minutos — Primeiros sintomas nos serviços** — Serviços de fee calculation, quoting e execução de trades começam a apresentar latência elevada e timeouts. Produtores Kafka em partições sem líder começam a falhar ou bloquear. Os alertas iniciais são ambíguos — parecem problemas de aplicação ou latência de rede. 3. **T+X — Diagnóstico inicial incorreto** — As equipes investigam os serviços de aplicação e a infraestrutura de rede. Os brokers Kafka aparecem como saudáveis nas métricas padrão. A ausência de líderes em partições específicas não é imediatamente visível nos dashboards existentes. O tempo de diagnóstico é prolongado pela falta de observabilidade granular sobre o estado de líderes de partição. 4. **T+Y — Identificação do MSK como causa raiz** — A equipe identifica que as partições afetadas estão sem líderes ativos e que os clusters estão presos no estado 'healing'. O problema é escalado para a AWS. Confirma-se que o defeito está no control plane do MSK, fora do controle da Coinbase. 5. **T+Z — Intervenção da AWS e início da recuperação** — A AWS intervém no control plane para remediar o defeito. Os clusters começam a sair do estado 'healing'. A reeleição de líderes de partição é retomada. Os serviços da Coinbase começam a recuperar gradualmente à medida que os tópicos voltam a ter líderes ativos. 6. **T+horas — Recuperação completa** — Todos os serviços de trading são restaurados. A equipe inicia a análise post-mortem. O incidente é classificado como Severidade 1 com impacto crítico em receita e experiência do cliente. ## Fluxo de Falha: MSK Control Plane e Serviços de Trading Este diagrama reconstrói o fluxo de falha do incidente de 7 de maio de 2026. O control plane do MSK (operado pela AWS, fora do controle da Coinbase) entrou em estado defeituoso, bloqueando a reeleição de líderes de partição nos dois clusters afetados. Os serviços de trading que dependiam dessas partições ficaram sem capacidade de produzir ou consumir mensagens de forma confiável. ### ☁️ AWS MSK — Control Plane (AWS-operated) - MSK Control Plane (AWS-managed) (external) - MSK Cluster A state: HEALING 🔴 (messaging) - MSK Cluster B state: HEALING 🔴 (messaging) - Partições sem líder (leader re-election bloqueada) (data) ### 🏦 Coinbase — Serviços de Trading - Fee Service ❌ bloqueado (compute) - Quoting Service ❌ bloqueado (compute) - Trade Execution ❌ bloqueado (compute) - Kafka Producers timeout / error (compute) - Kafka Consumers offset stalled (compute) ### 👤 Usuários Finais - Clientes Coinbase trading indisponível (user) ### Fluxos - msk-cp -> msk-cluster-a: orquestra (defeituoso) - msk-cp -> msk-cluster-b: orquestra (defeituoso) - msk-cluster-a -> partition-leaderless: reeleição bloqueada - msk-cluster-b -> partition-leaderless: reeleição bloqueada - kafka-producer -> partition-leaderless: write → erro/timeout - partition-leaderless -> kafka-consumer: consume → stalled - fee-svc -> kafka-producer: publica eventos - quote-svc -> kafka-producer: publica eventos - trade-svc -> kafka-producer: publica eventos - kafka-consumer -> fee-svc: consome resultados - kafka-consumer -> trade-svc: consome resultados - end-user -> quote-svc: solicita quote - end-user -> trade-svc: submete ordem > **Causa Raiz: Defeito no Control Plane do AWS MSK:** Um defeito no control plane do Amazon MSK — a camada de orquestração operada exclusivamente pela AWS — impediu que dois clusters Kafka de produção completassem a reeleição automática de líderes de partição. Os clusters ficaram presos no estado interno 'healing', um estado de manutenção do qual não conseguiam sair sem intervenção externa da AWS. O resultado foi que múltiplas partições ficaram sem líder ativo, bloqueando produtores e consumidores de forma silenciosa — sem crash explícito, sem alerta de 'cluster down', sem erro de conectividade óbvio. A falha estava em uma operação de coordenação que deveria ser transparente e automática, mas que falhou de forma parcial e opaca. ## Blast Radius e Por Que Foi Tão Amplo 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'. ## Remediação: O Que a Coinbase Fez e O Que Precisa Mudar 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'. ## Lições do Incidente - **Serviços gerenciados têm control planes opacos.** O MSK é Kafka, mas não é *seu* Kafka. O control plane que gerencia reeleição de líderes, rebalanceamento e manutenção é operado pela AWS. Defeitos nessa camada são invisíveis para você e irremediáveis sem intervenção da AWS. Sua arquitetura precisa ser resiliente a essa opacidade. - **Falha silenciosa é pior que crash explícito.** Um cluster 'healing' que não progride é mais difícil de diagnosticar do que um cluster que recusa conexões. Invista em observabilidade que detecta ausência de progresso, não apenas presença de erros. - **`UnderReplicatedPartitions` e `OfflinePartitionsCount` são métricas de alerta de primeiro nível.** Se você usa Kafka em produção para fluxos críticos e essas métricas não estão em seu runbook de on-call, corrija isso agora. - **Produtores Kafka sem timeout configurado são bombas-relógio.** `max.block.ms`, `request.timeout.ms` e `delivery.timeout.ms` devem ser configurados explicitamente em todos os produtores de serviços críticos. O padrão do Kafka é permissivo demais para sistemas financeiros. - **Circuit breakers precisam cobrir o cenário de 'Kafka lento/preso', não apenas 'Kafka down'.** A maioria das implementações de circuit breaker detecta erros de conexão. Poucos detectam 'produtor bloqueado por mais de N segundos'. Esse segundo cenário é o que aconteceu aqui. - **Dependência de dois clusters no mesmo control plane é um ponto único de falha lógico.** Mesmo que sejam clusters 'diferentes', se ambos são MSK na mesma conta/região e o control plane falha, ambos são afetados simultaneamente. Diversificação real requer isolamento de control plane. > **Minha Leitura Sênior:** Esse incidente me incomoda de uma forma específica: ele é exatamente o tipo de falha que equipes experientes com Kafka não antecipam, porque o Kafka auto-gerenciado raramente falha *dessa forma*. Quando você opera seu próprio Kafka, você tem visibilidade sobre o ZooKeeper ou o KRaft controller, você pode intervir diretamente, você pode forçar uma reeleição de líder. Com o MSK, você terceirizou essa camada — e com ela, a capacidade de agir quando ela falha. O que eu faria diferente na arquitetura? Três coisas concretas. **Primeiro**, nunca deixaria serviços de trading críticos com dependência direta e síncrona de um único path Kafka sem um mecanismo de fallback explícito. Para fee e quoting, existe quase sempre um caminho de cálculo síncrono mais lento mas funcional — esse caminho precisa existir e ser testado regularmente. **Segundo**, implementaria um 'Kafka health watchdog' dedicado: um processo simples que tenta produzir e consumir em um tópico de heartbeat a cada 30 segundos e alerta se o round-trip exceder um threshold. Não confio em métricas de infraestrutura para detectar falhas parciais — quero uma prova de liveness end-to-end. **Terceiro**, e mais importante: testaria o cenário de 'MSK em estado de manutenção irrecuperável' no meu game day anual. Não 'MSK down' — isso é fácil. 'MSK respondendo mas sem líderes em partições críticas'. Esse cenário específico é o que pegou a Coinbase de surpresa, e é o que vai pegar a próxima empresa também se ela não testar explicitamente. Sobre a decisão de usar MSK: não acho que foi um erro. Kafka auto-gerenciado em escala da Coinbase tem seus próprios riscos operacionais significativos. O erro foi não ter modelado explicitamente o risco de falha opaca do control plane e não ter construído as defesas correspondentes. Serviços gerenciados não eliminam risco — eles trocam um conjunto de riscos por outro. Sua arquitetura precisa refletir essa troca. ## Veredicto O incidente de 7 de maio de 2026 na Coinbase é um estudo de caso sobre o **custo oculto da abstração em infraestrutura crítica**. O Amazon MSK entregou o que prometeu na maior parte do tempo — Kafka gerenciado, sem a carga operacional de operar brokers. O que não estava no contrato implícito era: 'e quando o nosso control plane falhar de forma opaca, você não vai conseguir fazer nada até que a gente intervenha'. Não há vilão aqui. O MSK falhou de uma forma que a AWS provavelmente também não antecipava — defeitos em control planes de serviços gerenciados são raros e geralmente corrigidos rapidamente. O problema não é que o MSK falhou. O problema é que a arquitetura da Coinbase não estava preparada para o cenário de 'Kafka parcialmente disponível com partições sem líder' — um cenário que é mais difícil de detectar, mais difícil de diagnosticar e mais difícil de remediar do que uma falha total. A lição central não é 'não use serviços gerenciados'. É: **quando você usa um serviço gerenciado para uma função de coordenação crítica, você precisa construir observabilidade e resiliência para os modos de falha específicos desse serviço gerenciado** — incluindo os modos de falha que são opacos para você. Isso significa métricas de saúde de partição em alertas de primeiro nível, timeouts agressivos em produtores e consumidores, circuit breakers que detectam lentidão além de erros, fallbacks para caminhos críticos, e game days que testam explicitamente o cenário de 'serviço gerenciado em estado de manutenção irrecuperável'. A Coinbase tem a maturidade de engenharia para implementar todas essas defesas — e o post-mortem público demonstra a cultura de responsabilidade necessária para fazê-lo. O custo foi alto. As lições são transferíveis para qualquer equipe que usa Kafka gerenciado — ou qualquer serviço gerenciado — em fluxos críticos de negócio. ## Referências - [Coinbase — A postmortem of our May 7, 2026 outage](https://www.coinbase.com/blog/a-postmortem-of-our-may-7-2026-outage) ## Fontes do caso - [Coinbase — A postmortem of our May 7, 2026 outage](https://www.coinbase.com/blog/a-postmortem-of-our-may-7-2026-outage)