Arquitetura: o que funciona, e como verificá-lo

O Math Challenge funciona inteiramente sobre a Cloudflare. Esta página separa o que já está a funcionar do que apenas está desenhado, e dá o comando que comprova cada afirmação.

Última verificação contra a produção: 2026-07-31

O que está a funcionar hoje

math-challenge-web — Um Worker com Astro e Static Assets, que serve os sete locales e as rotas que estão por trás deles.
math-challenge-ingest — Um segundo Worker sem qualquer rota pública. Só é alcançado por service binding a partir do primeiro.
math-challenge-db — Uma base de dados D1 na região WNAM. A jurisdição fixa-se ao criar a base e depois já não pode ser alterada — uma porta que se fechou no dia em que foi criada, e que fica escrita em vez de ser descoberta mais tarde.
Dois espaços de KV: os tokens de sessão de curta duração, e os sinalizadores de funcionalidade com a cache do catálogo de conteúdos.
Dois baldes do R2: os conteúdos multimédia, e o arquivo frio onde serão escritas as exportações de dados pessoais.
Analytics Engine, com o binding declarado e reservado para a telemetria de tentativas e o desempenho de terreno. Ainda ninguém lhe escreve: um conjunto de dados do Analytics Engine só nasce da primeira vez que um Worker lhe escreve.

Todo o resto do inventário está desenhado e não criado. Está listado mais abaixo, nome a nome, porque uma página que só mostra as peças que existem é um folheto.

HTTP/3, QUIC e 0-RTT

O HTTP/3 sobre QUIC está ligado na zona, e a retoma 0-RTT também, que permite a quem regressa enviar o primeiro pedido sem pagar um novo aperto de mão. Nenhuma das duas é afirmada a partir de uma página de documentação: as duas linhas abaixo foram lidas diretamente da produção, pela mesma verificação que corre depois de cada implementação. Um interruptor que alguém desliga num painel não deixa rasto no repositório: o código não daria por isso.

Lido da produção na data acima:

alt-svc: h3=":443"; ma=86400
TLS 1.3 · Max Early Data: 14336

O que isto não resolve: o HTTP/3 acelera o transporte, não o trabalho. Um pacote pesado de JavaScript bloqueia a linha de execução principal sobre QUIC exatamente como sobre TCP. Por isso o orçamento de peso mais abaixo importa mais do que o protocolo.

RPC nativo entre Workers

Os dois Workers falam entre si por um service binding, com chamadas a métodos tipados em vez de pedidos HTTP. A Cloudflare descreve o que isso custa:

When you use Service Bindings, there is zero overhead or added latency. By default, both Workers run on the same thread of the same Cloudflare server.
RPC to another Worker (over a Service Binding) usually does not even cross a network. In fact, the other Worker usually runs in the very same thread as the caller, reducing latency to zero.

Cloudflare, documentação dos Service Bindings e anúncio do RPC nativo de JavaScript

Um RPC que não atravessa a rede não pode ser superado por um que atravessa, por mais eficiente que seja a sua serialização. O caminho completo — primeiro Worker, segundo Worker, D1 — responde num ponto público de estado, por isso verifica-se em vez de se acreditar.

Porquê não gRPC

O gRPC foi pedido pelo nome. A investigação descartou-o por três factos independentes, cada um suficiente por si só:

O Workers não consegue fazer chamadas gRPC de saída. O runtime não tem streaming bidirecional de HTTP/2, e há um problema aberto no repositório do próprio runtime da Cloudflare a segui-lo.
O navegador também não fala gRPC. O cliente web implementa outro protocolo, recorre a HTTP/1.1 — o que anula parte das vantagens — e não suporta nem streaming de cliente nem chamadas bidirecionais.
Os trailers de HTTP, de que o gRPC precisa para transportar o estado, têm suporte limitado no proxy de fronteira da Cloudflare. Quem o documentou foi a própria Cloudflare.

O que sobrou não é prémio de consolação. Adotar gRPC aqui teria sido adotar a geração anterior com mais trabalho e menos resultado. O pedido e a prova que o derrubou estão ambos no registo público de decisões: é para isso que ele serve.

Zero pedidos a terceiros

Sem CDN de tipos de letra, sem script de analítica, sem moldura incorporada, sem folha de estilos externa. Nem um pedido sai para um servidor que não seja nosso. Isto é verificado contra o HTML que a produção serve mesmo, não contra as nossas intenções.

A Raleway é alojada por nós como tipo de letra variável, em dois ficheiros: latin e latin-ext. O segundo não é opcional: sem ele, o ñ, o ç, o ã, o õ e o ü de cinco dos nossos locales recorrem a outra tipografia, precisamente nos caracteres que os tornam aqueles locales. E a razão que pesa mais do que o desempenho: carregar um tipo de letra de um terceiro entrega a esse terceiro o endereço e a assinatura de navegador de cada visitante, nas páginas públicas de um produto para crianças.

A inferência corre dentro da rede

Os 23 auditores adversariais já correm sobre o Workers AI, e o tutor vai também para lá: a inferência fica na Cloudflare em vez de ir para uma API externa. A chamada acontece dentro do Worker, sem viagem externa, e o aparelho de referência é um telemóvel Android de gama baixa em dados móveis lentos, onde a latência custa tanto como o preço.

Aquilo a que isso renuncia fica escrito em vez de disfarçado. O modo JSON do Workers AI é de melhor esforço, por isso a validação de esquema é connosco. Um veredicto que não valida conta como auditor falhado, nunca como auditor limpo: o modo de falha barato é voltar a correr, e o caro é uma violação que ninguém viu.

As tentativas nunca vão para o D1

O D1 tem um limite de 10 GB por base de dados. Uma linha por tentativa chegaria a essa parede por erro de desenho e não por crescimento: o primeiro limite duro desta arquitetura atinge-se a errar, não a ter êxito. As tentativas em bruto vão para o Analytics Engine; o D1 fica com as contas, os metadados de conteúdo e os agregados. Um auditor determinista bloqueia o commit que se esqueça disso.

Medimos nós, e nunca uma criança

O desempenho de terreno somos nós que o medimos e nunca um terceiro: um script embutido de cerca de 600 bytes que reporta a um ponto de entrada nosso, que escreve no Analytics Engine — nunca no D1 e nunca num serviço de fora. Nada do que envia identifica uma pessoa, e nunca é carregado no ecrã de uma criança: o ponto de entrada também recusa essas faixas, de modo que as duas pontas falham fechadas. Um auditor guarda o código; a verificação em produção guarda a outra metade, porque a plataforma pode injetar uma baliza sua ao nível da zona e isso não deixa ficheiro nenhum para inspecionar.

Quanto pesam as páginas

Página mais pesada: 9,5 KB comprimidos com gzip, que é como viajam. Todo o JavaScript de cliente do sítio: 2,6 KB. Todo o CSS: 1,5 KB. O orçamento que bloqueia um commit é de 12 KB por página e 60 KB para todo o JavaScript de cliente somado.

Medido na data acima. Corra você mesmo o auditor e obtém o número em vez da nossa palavra.

O orçamento de desempenho, e o que ainda não afirmamos

O orçamento é INP abaixo de 150 ms, LCP abaixo de 2,5 s e CLS abaixo de 0,1. 150 e não os 200 do costume, porque este é um jogo de alta frequência de interação: uma criança toca muitas vezes por sessão e cada toque é medido. É exatamente o perfil onde o INP parte.

Dito sem enfeites: isso são orçamentos, não resultados. Nenhuma medição de terreno durou o suficiente para que o auditor que faz cumprir os limiares tenha o que fazer cumprir. Até lá, esta página não afirma qualquer resultado de desempenho.

A frota de auditores

8 auditores deterministas correm em cada commit, em milissegundos, e bloqueiam-no. 23 auditores adversariais com modelos de linguagem correm antes de abrir um pull request, instruídos para encontrar a violação e não para aprovar. Ao todo estão 39 planeados; 8 continuam à espera da fase que os habilita, e figuram como pendentes em vez de desaparecerem em silêncio.

Duas regras fazem com que sirvam em vez de atrapalharem. Cada auditor tem de citar a decisão ou o documento de investigação que faz cumprir: um que não consiga apontar um identificador real está a opinar, e o seu veredicto não bloqueia. E anular um auditor exige escrever porquê, num ficheiro que é commitado juntamente com a alteração que precisou da anulação.

O que ainda não existe

O inventário é escrito antes de os objetos existirem, para que quem criar um escreva a sua linha no registo no mesmo pull request. Um recurso criado e não documentado é um recurso que ninguém conseguirá apagar daqui a um ano. Isto está desenhado e não criado:

Durable Objects para ligas, turmas e o modelo adaptativo por criança — um por liga e um por turma, nunca um global.
Queues e Workflows para a correção assíncrona e a geração de explicações.
Um índice do Vectorize para pesquisa sobre o banco de pistas curadas, restrito a conteúdo curado e nunca a vetores por criança.
O próprio banco de itens, que é o produto e não um conjunto de dados.

Quem opera isto, e quem fornece

A Ignia opera a infraestrutura. Cada objeto que esta página nomeia vive numa conta da Cloudflare que a Ignia gere — operar contas da Cloudflare, para os seus próprios produtos e para os seus clientes, faz parte daquilo que a Ignia faz. O Math Challenge é um projeto da Ignia, patrocinado pela Ignia.

A Cloudflare fornece a plataforma. Workers, D1, KV, R2, Analytics Engine e a rede onde correm são produtos da Cloudflare, operados pela Cloudflare. A Ignia opera; a Cloudflare fornece. Dois verbos, duas empresas, mantidos separados de propósito — e a razão para os manter separados é aquela em que assenta toda esta página: quem lê uma página de arquitetura é quem verifica.

Uma dessas duas metades cabe numa consulta pública de DNS. Lida na data acima:

dig +short NS math.kilowatto.com
alberto.ns.cloudflare.com.
colette.ns.cloudflare.com.

A outra metade não se consulta em lado nenhum, e dizemo-lo. Que este domínio é servido pela Cloudflare, qualquer pessoa o confirma. Que a Ignia opera a conta é uma afirmação nossa: não há registo público onde a ir confrontar. Dizê-lo assim vale mais do que enfeitá-lo, porque basta uma única afirmação que não se possa verificar para o leitor deixar de verificar as restantes.

O que esta página não afirma, de propósito: que a Ignia seja parceira da Cloudflare. Não citamos nenhum nível de parceria nem mostramos selo algum, porque não existe diretório público onde o pudesse verificar. Numa página cuja promessa inteira é «e é assim que se verifica», uma afirmação que não se pode verificar custa mais do que vale.

A Ignia, nas suas próprias palavras: ignia.cloud

Como verificar qualquer uma destas coisas

o anúncio de HTTP/3 nos cabeçalhos de resposta

curl -sI https://math.kilowatto.com/en/ | grep alt-svc

0-RTT: o bilhete de sessão do TLS 1.3 e a sua permissão de dados antecipados

openssl s_client -connect math.kilowatto.com:443 -tls1_3 -sess_out s.pem
openssl sess_id -in s.pem -text | grep "Max Early Data"

o caminho de RPC: primeiro Worker, segundo Worker, D1

curl -s https://math.kilowatto.com/api/health

os pesos citados acima, a partir do repositório

node audits/bundle-budget.mjs

Fontes

O Math Challenge é um projeto da Ignia, e corre sobre a Cloudflare. São duas afirmações e mantêm-se separadas de propósito: dizer que a Ignia fornece a infraestrutura seria desmentido por uma única consulta de DNS, e quem lê uma página de arquitetura é exatamente quem a faria. ignia.cloud