Em 12 de agosto, a Cloudflare concluiu a migração de seu blog para o EmDash, um sistema de gerenciamento de conteúdo desenvolvido para funcionar com Astro e Cloudflare, em um projeto que não se limitou a uma reformulação da interface. A empresa usou seu blog como o “cliente zero” para testar a nova plataforma em tráfego de produção real, com foco em escalabilidade, velocidade de resposta e segurança da transição do sistema antigo.
A Cloudflare afirma que o processo de migração revelou necessidades relacionadas ao tamanho e à complexidade do blog, além de permitir que a equipe aprimorasse o EmDash antes de disponibilizá-lo em uma escala maior. Como os resultados e as métricas são apresentados pela própria empresa, eles representam uma experiência operacional publicada por uma única parte, e não um teste independente da plataforma.
Testando a plataforma antes dos testes de desempenho
A equipe começou com uma pergunta prática: o EmDash realmente atende às necessidades da Cloudflare? Para isso, testou fluxos essenciais, como criar, publicar, retirar da publicação e agendar posts, adicionar mídia, além de pesquisar entidades de conteúdo e gerenciar nomes de autores.
As maiores lacunas apareceram no tratamento do grande volume de mídia e conteúdo, bem como nos detalhes de tradução, otimização para mecanismos de busca e políticas de segurança de conteúdo (CSP). O editor administrativo também precisou de melhorias para localizar blocos HTML personalizados, lidar com erros no editor de conteúdo e manter a barra de formatação visível durante a edição de posts longos.
Os posts agendados foram o principal problema descoberto, pois não funcionavam até a versão 0.19.0 do EmDash. Esse ponto demonstra o valor de testar fluxos operacionais completos antes de adotar um novo sistema, já que a falha necessariamente não apareceria em um teste de criação de conteúdo ou de publicação imediata.
Testes de carga que simulam tráfego variável
O tráfego habitual do Cloudflare Blog ficava em torno de 75 solicitações por segundo, mas podia ultrapassar 5.000 solicitações por segundo, seja simultaneamente à viralização de um novo post, seja por picos não relacionados a um horário específico de publicação. Por isso, a equipe criou testes usando a ferramenta de código aberto k6, incluindo um aumento gradual da carga até três vezes a linha de base, um teste que começava em zero e chegava a 100 solicitações por segundo em dez minutos e um teste de explosão instantânea a 7.000 solicitações por segundo durante um minuto.
Os critérios de falha baseavam-se em três indicadores: os erros HTTP da categoria 5xx não poderiam ultrapassar 0,01%; o tempo de resposta de 95% das solicitações não poderia exceder 500 milissegundos; e o tempo de resposta de 99% delas não poderia exceder um segundo. Esses limites transformaram a pergunta “a plataforma é rápida?” em condições operacionais mensuráveis.
Arquitetura em várias camadas e um caminho claro de reversão
A Cloudflare escolheu executar o EmDash em um Cloudflare Worker atrás do Workers Cache, usando o novo armazenamento de objetos do EmDash baseado no Workers KV e a integração do Hyperdrive com o PlanetScale. As camadas de cache permitiram servir 99,5% dos arquivos estáticos a partir do cache e cerca de 70% do total de solicitações dessa forma, segundo dados da empresa, reduzindo a pressão sobre o banco de dados.
Para evitar uma interrupção do serviço durante a transição, a equipe criou um Proxy Worker que distribuía as solicitações entre o blog antigo e o novo site. Ele identificava a versão de teste por meio de um cookie, com a possibilidade de redirecionar as solicitações para o sistema antigo quando surgissem erros 500 no novo site. A equipe também usou uma conexão direta entre Workers por meio da vinculação do serviço NEW_BLOG, evitando passar por um nome de domínio público, operações de DNS e TLS e uma conexão HTTP externa.
O lançamento gradual começou com 1% do tráfego, depois subiu para 5% e 15%, antes de chegar a 100% no fim do dia. Isso permitiu monitorar a carga real e descobrir casos extremos sem expor a maioria dos leitores a uma mudança instável.
O que mudou na prática?
A Cloudflare afirma que a nova arquitetura manteve um tempo de resposta mais estável em comparação com a plataforma anterior, com ganhos de desempenho e erros limitados ao atender até 850 solicitações por segundo. Durante a Agents Week, foram publicados 18 posts em nove dias, alcançando quase 3 milhões de visualizações, e o novo Worker atendeu até 450 solicitações por segundo sem problemas perceptíveis. A proteção DDoS integrada também absorveu um ataque de 28.000 solicitações por segundo em 10 de agosto, segundo a empresa.
A mudança também incluiu a interface, reconstruída de acordo com os padrões do sistema de design Kumo, com suporte nativo aos modos claro e escuro, baseado nas preferências do sistema e em um alternador manual. O convite para inscrição por e-mail foi transferido para o fim do artigo, e foram adicionados um índice “Nesta página” e a opção “Discutir online” para melhorar a navegação e o compartilhamento.
As novas interfaces do EmDash e os pontos de busca de inteligência artificial permitiram criar, em poucas horas, um servidor MCP para o blog da Cloudflare, com ferramentas para pesquisar, listar e recuperar posts, além de listar tags. O servidor MCP do EmDash também permite que os autores naveguem pelo conteúdo, criem, editem, publiquem e agendem conteúdo e removam arquivos sem custo adicional, segundo a fonte.
A própria experiência de edição continua incompleta; a Cloudflare continuou registrando pequenos problemas e erros relacionados a posts agendados e afirmou que os encaminhou à equipe do EmDash, esperando corrigi-los antes da Birthday Week. Portanto, o caso não comprova que a plataforma esteja livre de limitações, mas demonstra uma prática aplicável: testar os fluxos de conteúdo antes do desempenho, definir limites de falha explícitos, criar um caminho de reversão e, então, ampliar a implantação gradualmente, em vez de realizar uma transição completa de uma só vez.