Quando decidimos relançar o site da Elegant Garden Software com uma área de blog dedicada, tínhamos uma escolha clara pela frente. Tratar isso como um projeto de marketing tradicional, um WordPress, um tema, alguns plugins, ou tratar como o que de fato é: um sistema de software que sustenta um canal estratégico.
Optamos pelo segundo caminho. E essa escolha, aparentemente técnica, carrega uma tese organizacional que vale tornar explícita.
O Design System como gramática do CMS
A escolha de um CMS headless, no nosso caso, o Strapi, não é nova. O que talvez seja menos comum é como modelamos os Content Types.
A tentação inicial em qualquer CMS é modelar conteúdo a partir de um vocabulário editorial: título, subtítulo, corpo do texto, imagem destacada. Funciona, mas cria um problema silencioso. A cada novo tipo de artigo, alguém (autor, editor, designer) precisa decidir como aquilo deve ficar visualmente. A consistência depende de disciplina humana.
Nossa abordagem foi inverter a relação. O Design System da Elegant Garden é o vocabulário primário. Os Content Types do Strapi são definidos como composições desse vocabulário. Cada componente do DS, um bloco de código anotado, um decision record, uma citação com fonte, um diagrama de arquitetura, corresponde a um tipo customizado no Strapi, com campos que mapeiam exatamente os slots semânticos do componente.
O autor de um artigo não escolhe tipografia, espaçamento ou cor. Escolhe que tipo de bloco semântico vai usar e a renderização é determinística.
O efeito prático é interessante. A consistência visual deixa de ser uma meta editorial e passa a ser uma propriedade emergente da arquitetura. Para escapar do DS é preciso esforço deliberado, não negligência. Esse é o tipo de pressão que arquitetura bem-feita cria.
Publicação via Lambdas em Go acionadas por webhooks
A segunda decisão foi sobre o caminho do conteúdo até o leitor.
A opção mais comum seria servir o blog dinamicamente a partir do Strapi, com um frontend consumindo a API. Optamos por outro caminho. O site final é estático, hospedado em S3 e servido via CloudFront. O Strapi nunca aparece no caminho crítico de leitura.
A ponte entre o CMS e o site estático é um pipeline serverless escrito em Go. Webhooks do Strapi disparam em eventos de criação, atualização e remoção de entradas. Lambdas AWS em Go recebem o webhook, buscam o estado atual do artigo, aplicam os templates correspondentes aos componentes do DS e regeneram os artefatos estáticos afetados, a página do artigo, os índices de listagem, sitemap e feeds. Em seguida, disparam invalidação seletiva de cache no CloudFront.
Por que Go? Por consistência com o resto da nossa stack (Polinize, Magic Auth e Moyy) são todos Go, e porque o ciclo curto de execução compensa o cold start.
Por que estático? Três razões. A primeira é performance e custo: servir HTML pré-renderizado de um CDN é barato e rápido. A segunda é resiliência: o blog continua disponível mesmo que o Strapi esteja indisponível, em manutenção ou sob ataque. A terceira, mais sutil, é que separar o caminho de autoria do caminho de leitura nos permite evoluir cada lado independentemente, e nos força a tratar o conteúdo publicado como um artefato versionado, não como efeito colateral de um banco de dados.
É uma espécie de CQRS aplicado a conteúdo. O write side é o Strapi, com modelo relacional, validações e workflow editorial, otimizado para autoria e governança. O read side é HTML estático em CDN, denormalizado por página, otimizado para latência e escala. As
Lambdas são a projeção que materializa um no outro, disparada por eventos. Não é CQRS no sentido estrito, não há event sourcing, e o read side é estático em vez de um sistema vivo, mas a propriedade essencial está lá: a fonte da verdade é o write side, e o read side é descartável e reconstruível.
Daí decorre um princípio operacional importante: o CMS é a fonte da verdade; o site é uma projeção determinística dela. Reproduzir o site a partir do CMS deve ser sempre possível. Recuperar o CMS a partir do site, deliberadamente não. Isso simplifica drasticamente o modelo mental de operação.
Marketing como software de primeira classe
A terceira decisão é organizacional, não técnica, mas é a que dá sentido às duas anteriores.
Estamos montando na Elegant Garden uma estrutura dedicada de marketing digital. E a premissa fundadora dessa estrutura é que ela compartilha a mesma espinha dorsal arquitetural dos nossos produtos. Mesmo Design System. Mesmo padrão de infraestrutura como código com OpenTofu. Mesma stack de observabilidade. Mesmas práticas de engenharia, testes, code review, CI/CD, SLOs.
Isso significa que landing pages, sequências de email, dashboards de mensuração e o próprio blog são tratados como sistemas de software de primeira classe, não como entregas pontuais de uma agência. Significa também que a fronteira entre produto e marketing fica deliberadamente borrada nas camadas de infraestrutura, mesmo que os times e objetivos sejam distintos.
A hipótese que estamos testando é simples. Tratar marketing como sistema de software de primeira classe muda qualitativamente o que se consegue fazer com ele. Ciclos de iteração mais curtos, experimentação mais barata, mensuração mais rigorosa. E, talvez o mais importante, uma narrativa coerente entre o que dizemos sobre engenharia e como fazemos engenharia para nos comunicarmos.
E você, como tem pensado a fronteira entre Tecnologia e Marketing na sua empresa?