D1: tire o plano de controle do caminho comum da consulta

A Cloudflare explicou como o plano de controle do D1, banco gerenciado baseado em SQLite, administra milhões de bancos sem centralizar cada consulta.[15] O serviço separa plano de dados, administração e processamento assíncrono de análise e cobrança.[15] A lição para um SaaS não é copiar essa infraestrutura inteira: é identificar quais operações precisam de decisão central e quais podem seguir um caminho distribuído.

O que muda para quem desenvolve

Cada banco D1 tem um Durable Object SQLite por trás, enquanto APIs administrativas usam um Worker e Postgres central para metadados.[15] No caminho comum das consultas, Workers KV guarda informações de roteamento para evitar a ida ao Postgres.[15] Bindings de aplicações Workers também carregam informações de acesso e encaminhamento.[15]

Na criação, o serviço inicializa o objeto e depois persiste o mapeamento no Postgres; essa gravação é o ponto em que o banco passa a existir no plano de controle.[15] Uma resposta perdida ao cliente não desfaz esse fato.[15] A equipe evita manter uma transação Postgres aberta durante a inicialização remota.[15]

Minha leitura é que a arquitetura assume a possibilidade de estados intermediários, em vez de tentar esconder tudo numa transação global. Para aplicar o padrão, nomeie esses estados e defina quem os reconcilia. Uma etapa de melhor esforço precisa ter consequência conhecida se falhar.

O D1 usa heartbeats a cada 30 segundos, com variação por banco, para corrigir mapeamentos e desativar objetos órfãos.[15] Na exclusão, o próprio Durable Object guarda o estado e rejeita consultas mesmo quando um cache ainda indica atividade.[15] A decisão crítica permanece no componente capaz de impedir o efeito.

Como aplicar

Desenhe separadamente consulta do usuário, criação e exclusão de recursos, cotas e cobrança. Para cada fluxo, anote onde está a decisão autoritativa e quanto atraso é aceitável. Não imponha a mesma consistência a tudo por conveniência.

Em um protótipo sem dados reais, simule falha após criar o recurso, antes de gravar seu mapeamento e depois de gravá-lo sem responder ao cliente. Exija que a reconciliação alcance um estado válido ou desative o órfão. Observe também o comportamento das novas tentativas.

Para contadores, compare atualização direta de um total compartilhado com um fluxo de deltas agregados. O D1 publica tamanhos em filas, registra deltas e agrega mudanças por conta antes de atualizar o total.[15] Defina no experimento como detectar atraso e recuperar processamento interrompido.

Cuidados e limites

Workers KV é usado como armazenamento durável de roteamento, não apenas um cache descartável.[15] Uma solução própria que trate todos os metadados distribuídos como descartáveis não terá automaticamente a mesma proteção contra concentração de leituras no banco central.

A aplicação de cotas aceita algum atraso em troca de escala e disponibilidade.[15] Essa troca precisa ser compatível com o produto. Use a arquitetura como referência para discutir estados, reconciliação e limites; não como garantia de custo, localização ou consistência para qualquer aplicação multitenant.

Fonte

[15] Fonte: Cloudflare Blog