o problema
Por quase uma década a resposta prática para “meu banco não aguenta mais” foi desistir do banco. Sistemas no estilo Bigtable escalavam horizontalmente sem drama, mas devolviam ao programador tudo que o modelo relacional tinha absorvido: sem join, sem transação que cruze linhas arbitrárias, sem schema com garantia, sem uma linguagem de consulta que outra pessoa da empresa consiga ler. Quem escolhia esse caminho ganhava escala e passava a manter, na camada de aplicação, uma reimplementação pior de um banco de dados.
O outro lado tinha o problema simétrico. SQL com consistência forte era usável e correto, mas escalava por sharding manual, e sharding manual é uma dívida que vence sempre no pior momento. O resumo do F1 diz que ele foi construído para sustentar o negócio do AdWords — ou seja, uma carga transacional real, com dinheiro dentro, que não podia perder consistência nem parar de crescer. É esse enquadramento que explica o esforço: não era um exercício de pesquisa sobre o que é possível, era um sistema que precisava existir para um negócio que já estava rodando.
a ideia
F1 se descreve como híbrido, e a palavra é literal: alta disponibilidade e escalabilidade no estilo dos sistemas NoSQL, consistência e usabilidade dos bancos SQL tradicionais, no mesmo sistema. O movimento que torna isso viável é não tentar resolver tudo numa camada só. F1 é construído sobre o Spanner, e é o Spanner que fornece replicação síncrona entre datacenters e consistência forte. F1 fica por cima com o que falta para aquilo parecer um banco relacional: schema, SQL, transações utilizáveis por quem escreve aplicação.
A parte honesta do resumo é a frase seguinte. Replicação síncrona implica commit mais lento — não tem mágica, é a velocidade da luz somada ao número de réplicas que precisam concordar. O F1 não resolve isso; ele muda o lugar onde o custo aparece. Em vez de otimizar o protocolo, os autores otimizam o formato dos dados: um modelo de schema hierárquico, com tipos de dados estruturados, que aproxima o que costuma ser lido e escrito junto. Se a unidade natural de trabalho da aplicação cabe num pedaço coeso do schema, uma transação atravessa menos fronteiras e sofre menos rodadas de coordenação. Some a isso o que o resumo chama de smart application design, e a latência maior por commit deixa de significar latência maior por operação de negócio.
Além do núcleo transacional, o F1 traz duas peças que normalmente ficariam fora do banco: uma engine de consulta SQL distribuída completa, e rastreamento e publicação automática de mudanças. A segunda é fácil de subestimar. Quando o banco sabe publicar o que mudou, todo o ecossistema de índices, caches e sistemas derivados para de depender de gente lembrando de emitir evento.
o que isso custou
O próprio resumo entrega o preço numa frase: commit mais caro. Esse é o custo estrutural, e ele não some — é mitigado. Mitigado, aqui, quer dizer que uma parte do trabalho foi transferida para quem modela o schema e para quem escreve a aplicação. Um sistema que exige schema hierárquico e design cuidadoso para ter latência aceitável não é um substituto transparente para um banco relacional comum: é um banco relacional com opinião forte sobre como seus dados devem estar organizados. Quem chega com um schema plano e normalizado no reflexo antigo não colhe o benefício.
Há também a dependência. F1 não é portável para fora do Spanner, porque as garantias que ele oferece são as garantias que o Spanner oferece. E o resumo não diz o que veio antes nem quanto custou migrar — esse verbete descreve o que o resumo sustenta, não os experimentos e a arquitetura do texto completo.
onde isso aparece hoje
F1 é o argumento que fechou a discussão sobre se NewSQL era possível fora do slide. Ele fica na mesma linhagem do Spanner, de quem depende diretamente, e responde à escala que o Bigtable tinha conquistado ao preço da usabilidade — o mesmo impasse que o Megastore já havia atacado por outro caminho no Google. A geração seguinte de bancos distribuídos open source assume publicamente essa herança: o TiDB separa camada SQL de camada de armazenamento com consistência forte exatamente nesse molde.