antonio leandro

comentariotechen

Marc Brooker

Engenheiro sênior da AWS há quase duas décadas, EBS, Lambda, Firecracker, Aurora DSQL e hoje ferramentas de IA para código. Escreve desde 2012 sobre filas, consenso, bancos distribuídos e por que coordenar é o que custa caro.

163 textos no acervo · publica a cada ~16 dias · último em

escrito por pipeline de llm, revisado por antonio leandro antes de publicar

o que esta fonte defende

Há uma tese que atravessa quase tudo: coordenação é o imposto que limita a escala, e quase todo bom projeto de sistema é um jeito de pagar menos dele. Brooker repete essa ideia em registros diferentes — em teoria (consenso e Paxos não são o que faz sistemas escalarem; particionamento é), em economia (commit atômico é “o protocolo da inescalabilidade”), em produto (o DSQL evita coordenação no caminho da transação e paga o preço em outro lugar) e em prosa didática (chaves quentes, distribuição de Zipf, false sharing). O corolário que ele defende com igual insistência é sobre medição: a média mente, o percentil alto é o que o cliente sente, e um benchmark sem distribuição — sem gráfico, sem eCDF, sem modelo aberto versus fechado — não é evidência de nada. Um terceiro fio, mais silencioso, é o de que simplicidade é uma escolha de quem constrói, feita em nome de quem usa: consistência forte, isolamento de snapshot e serverless são, no argumento dele, formas de mover complexidade para dentro do sistema para que ela não apareça na cabeça do desenvolvedor.

Onde ele mudou de ideia, mudou de forma visível e documentada. O arquivo começa em 2012 num engenheiro de performance de baixo nível — volatile em Java, lock elision no Haswell, armadilhas do iostat — e migra para teoria de sistemas distribuídos e, depois de 2019, para relatos de quem está construindo os sistemas sobre os quais teoriza. A mudança mais nítida é sobre o CAP: em 2014 ele o critica mas propõe substituí-lo por PACELC, um enquadramento melhor; em 2024 escreve que o teorema deveria ir para o gabinete de curiosidades, porque virou desculpa para não pensar. Junto com isso vem uma virada sobre consistência: quem começou explicando trade-offs com neutralidade passou a argumentar, em 2025, que consistência eventual simplesmente torna a vida de quem escreve aplicação mais difícil — uma posição que ele liga explicitamente à experiência de construir e operar bancos de dados na AWS, não a um argumento abstrato.

A virada mais brusca é recente e cobre quase todo o material de 2025 e 2026. Ele passou a trabalhar com IA como ocupação principal e escreve como otimista declarado: diz que os últimos meses foram os mais empolgantes de trinta anos construindo software, e formula uma hipótese explícita — qualquer tarefa de código com especificação completa (forma fraca) ou com um oráculo determinístico (forma forte) vai se tornar trivial. Vale notar que isso não é uma ruptura tão grande quanto parece: desde 2020 ele escrevia que código só diz o que faz, não o que deveria fazer, e que a história do software é uma aproximação lenta entre programar e especificar. A IA, no argumento dele, é a continuação natural dessa curva, não um desvio. O que ele recusa é a bagunça: não usa modelo para escrever texto, considera pass@k uma métrica majoritariamente inútil, e trata segurança de agente como problema de caixa — o que o agente pode tocar — e não de boa intenção do modelo.

Uma quarta linha, menor em volume mas constante em quarenta anos de referências, é a de segurança operacional emprestada de fora da computação: avalanches, Chernobyl, o modelo de Rasmussen, ambientes de aprendizado “gentis” e “perversos”. É de lá que vem a posição dele de que postmortem não basta, de que retries e caches são armadilhas metaestáveis vendidas como boas práticas, e de que sistemas precisam ser operados porque falhas latentes se acumulam invisíveis.

por tema

filas, cauda e a estatística de quem espera (39 textos)

O bloco mais antigo e mais teimoso do arquivo. A tese é que o desempenho de um sistema é uma distribuição, não um número, e que a parte da distribuição que importa é a cauda: o cliente que espera um segundo enquanto a média diz cem milissegundos. Ele volta a isso por muitos caminhos — teoria de filas aplicada (lei de Little contada como narrativa, uma ou duas filas no supermercado, a economia contraintuitiva de sistemas balanceados), truques concretos que baixam a cauda sem trade-off doloroso (hedging, poder de duas escolhas aleatórias, best-of-k, filas estocásticas justas), e uma insistência de que a cauda tem preço em dinheiro, não só em experiência.

A outra metade do tema é metodológica e mais combativa: geradores de carga fechados mentem sobre saturação, histograma quase sempre perde para eCDF, benchmark sem gráfico é anedota, e a média não é inútil — é mal usada. A camada mais antiga desse bloco é de instrumentação e hardware real: latência que cresce mais devagar que banda, custo de troca de contexto, volatile e atômicos em x86, lock elision no Haswell, blktrace, e os dois campos do iostat que ele pede para ninguém mais usar.

coordenação: o imposto que limita a escala (28 textos)

Aqui está a tese central. Consenso, replicação e commit atômico são peças necessárias, mas não são o mecanismo que faz sistemas escalarem — o mecanismo é dividir o trabalho de modo que as partes não precisem conversar. Ele desmonta a leitura popular de Paxos e Raft como “ferramentas de escala”, mostra por que commit em duas fases é um teto e não um alicerce, e explora o espaço entre otimismo e pessimismo: sistemas que evitam coordenar apostam em suposições sobre o que os outros componentes estão fazendo, e o interessante é o que acontece quando a aposta falha.

O segundo eixo é consistência, e é onde ele mudou de posição ao longo dos anos. O arquivo tem uma fase inteira de pedagogia do CAP — comparações com PACELC, com harvest and yield, com as duas definições incompatíveis da palavra disponibilidade — que termina em 2024 num pedido explícito para aposentar o teorema. Depois disso ele passa a defender consistência forte de forma direta: isolamento de snapshot como o ponto doce do espectro, versionamento no lugar de coordenação, e o argumento de que consistência eventual empurra complexidade para o código de quem usa. Fecha o tema uma camada de material clássico bem explicado: replicação por viewstamps, detectores de falha, anomalia de Fekete, conhecimento comum, Sybil e a pergunta se o Bitcoin resolve consenso bizantino.

os sistemas que ele ajudou a construir (26 textos)

Brooker escreve sobre sistemas que operou, e isso muda o tom: são relatos de projeto, não resenhas. O Aurora DSQL ocupa o maior espaço — uma sequência de textos que abre o produto camada por camada (leitura e computação, transações e durabilidade, disponibilidade dentro dos limites da física) e culmina num paper completo em 2026. O argumento de produto embutido nesses textos é que complexidade é escolha: o banco deveria absorver particionamento, failover e escala elástica para que a aplicação não precise pensar neles.

Ao redor disso está o resto da carreira dele na AWS, contada com detalhe técnico raro: dez anos de Lambda e o PRFAQ original, sete anos de Firecracker e o paper de virtualização leve, carregamento de imagens de contêiner no Lambda, snapshots como ferramenta de partida rápida, MemoryDB, Physalia e seus milhões de bancos minúsculos, gestão de recursos no Aurora Serverless. Há também um fio de teoria de escalabilidade de bancos escrito como série — NoSQL e o que se jogou fora junto com a água do banho, chaves quentes e Zipf, false sharing — e alguns exercícios de projeto abertos, como o que um banco desenhado para SSD deveria parecer e como consertar UUIDv7 para uso em índices.

métodos formais como higiene, não cerimônia (10 textos)

A posição é curta e ele a defende há mais de dez anos: especificação formal — TLA+, P — não é luxo acadêmico, é prática de engenharia comum, do mesmo tipo que teste e revisão de código. Ele foi um dos divulgadores do uso de TLA+ dentro da AWS, escreveu a versão que saiu na CACM, e continua produzindo material de porta de entrada: como começar, como convencer um time a começar, como usar simulação numérica simples quando o modelo formal é caro demais.

A parte mais interessante é a ressalva honesta. Métodos formais, escreve ele, resolvem no máximo metade dos problemas dele: garantem que o protocolo especificado está certo, não que a especificação é a que o negócio precisava, nem que o código implementa a especificação. Daí a linha complementar de invariantes em produção como alternativa ao depurador, e a observação que dá título a um dos textos mais citados do arquivo: código só diz o que faz, e depurar é a diferença entre isso e o que ele deveria fazer.

metaestabilidade, retries e cultura de falha (20 textos)

Uma coleção de contrarianismos contra coisas que a indústria chama de boas práticas. Retries pioram a maioria das situações reais, porque são disparados justamente por sobrecarga; circuit breakers ajudam menos do que se imagina, a menos que você saiba qual problema está resolvendo, e funcionam melhor quebrando só as tentativas repetidas; caches criam modos de operação distintos e sistemas instáveis, porque o sistema sem cache quente nunca foi dimensionado para existir. O conceito que amarra tudo é metaestabilidade: sistemas que ficam presos num estado ruim depois que o gatilho já passou, e dos quais só se sai desligando e ligando — coletor de lixo incluído na lista de gatilhos.

A outra metade vem de fora da computação e é o que dá densidade ao conjunto. Segurança em avalanches, o modelo de gradiente operacional de Rasmussen, a pergunta sobre quanta culpa cabe a Dyatlov em Chernobyl, ambientes de aprendizado gentis e perversos. A conclusão recorrente é que postmortem não basta — pontos únicos de falha ficam invisíveis quando nada quebrou ainda — e que redundância só ajuda se você souber contra o quê está sendo redundante, o que ele trata como exercício de modelagem de ameaças aplicado a projeto distribuído.

ia, agentes e programação por especificação (14 textos)

Tudo desde meados de 2025, e é o assunto mais quente do arquivo. A posição é de otimista explícito: ele trabalha com IA como ocupação principal, diz que os últimos meses foram os mais empolgantes de trinta anos de carreira, e formula a coisa como hipótese testável — tarefa com especificação completa vira trivial (forma fraca); tarefa com oráculo determinístico vira trivial (forma forte). Daí a defesa de desenvolvimento guiado por especificação, e a rejeição direta da acusação de que isso é cascata redivivo: especificar não é congelar, é escrever o que você quer dizer.

O otimismo vem com bordas duras. Ele considera pass@k uma métrica majoritariamente sem valor para medir agentes; trata segurança de agente como um problema de caixa — o que o agente pode alcançar — e não de confiança no modelo; e discute o LLM como componente de sistema, sujeito às mesmas perguntas de falha e composição que qualquer outro. Há uma série sobre o efeito na profissão: o que ficou fácil e o que ficou difícil, o que acontece com quem está começando a carreira, e a admissão pessoal de que as heurísticas que ele usava para avaliar trabalho pararam de funcionar. Num texto curto ele registra que nenhum texto legível por humano no blog é escrito por modelo, embora use agentes o tempo todo para código.

carreira, escrita e como ler papers (26 textos)

Um bloco que ele mesmo identifica como “e-mails longos demais para colegas que perguntaram algo”, publicados porque não eram específicos do trabalho. O conselho mais repetido é evitar câmaras de eco negativas: todo setor tem seu bar dos amargurados, é confortável e não leva a lugar nenhum. Perto disso ficam textos sobre como fazer projetos grandes acontecerem, como gastar o próprio tempo, uma rubrica para decidir se vale construir a ratoeira melhor, o perigo de regras de bolso aplicadas sem entender o que está por trás, a doença do zero-um-infinito, e a observação de que hobbies servem a propósitos diferentes para pessoas diferentes — motivo pelo qual dois entusiastas do mesmo assunto podem se irritar mutuamente.

O segundo eixo é leitura de pesquisa. Ele mantém guias de como engenheiros devem ler papers (com três modos: buscar solução, descobrir, curiosidade), listas curadas de Lamport, Nancy Lynch, Barbara Liskov e virtualização, relatos de conferência (HotOS, OSDI/ATC) e um pedido para focar na parte boa em vez de exercitar ceticismo por esporte. Escrever aparece como habilidade central: escrever é mágica, e escreva sempre para alguém específico. Há também os desvios que o blog se permite — uma proposta com drones para reconstruir Arecibo, a história do celacanto, e química de cozinha com bicarbonato.

onde ela discorda de outras fontes do acervo

Ele briga com posições populares, e nomeia as brigas. Contra o argumento de que máquinas ficaram rápidas demais para justificar sistemas distribuídos — a tese de “sirva todos os seus clientes de um servidor só”, comum entre defensores de arquiteturas monolíticas — ele responde que escala nunca foi a única razão: disponibilidade, durabilidade e isolamento de falhas continuam exigindo distribuição. Contra a cultura do CAP como ferramenta pedagógica, que ele mesmo ajudou a alimentar por uma década, passou a defender aposentadoria completa. Contra quem trata consistência eventual como escolha neutra de trade-off, argumenta que ela só transfere o problema para quem escreve a aplicação. Contra caches e retries como boas práticas padrão, mostra os modos metaestáveis que ambos criam. E, no lado de IA, contra a comunidade de avaliação de agentes que usa pass@k, chama a métrica de basicamente inútil, e contra a leitura de que desenvolvimento guiado por especificação seria um retorno à cascata.

linha do tempo