Golden Paths que Funcionam: A Diferença entre Adoção e Obrigação
Exploramos como criar golden paths que não apenas existem, mas que são realmente adotados pelos desenvolvedores. A chave está na diferença entre adoção e obrigação e como isso impacta a eficiência e segurança da plataforma.
Golden Paths que Funcionam: A Diferença entre Adoção e Obrigação
No mundo do Platform Engineering, os golden paths surgem como uma solução para padronizar processos, reduzir a carga cognitiva dos desenvolvedores e garantir a conformidade sem comprometer a autonomia dos times de produto. No entanto, a realidade muitas vezes revela que a existência de um golden path não garante sua adoção. A verdadeira eficácia de um golden path reside em sua capacidade de ser adotado voluntariamente, não apenas imposto como obrigação.
Contexto
Em uma fintech com mais de 200 engenheiros e 40 equipes de produto, enfrentamos o desafio de múltiplas implementações para autenticação, tokenização e documentação de APIs. Cada equipe desenvolvia sua solução, resultando em inconsistências de segurança e duplicação de esforços. Era essencial criar caminhos que fossem seguidos porque facilitavam o trabalho, e não apenas porque eram mandatórios.
A Decisão
Nossa abordagem focou em construir paved roads — caminhos pré-construídos e opinativos que atendem à maioria das necessidades de forma simples e eficiente. O design dos golden paths seguia princípios claros: fácil de usar corretamente, difícil de usar incorretamente, e com conformidade embutida. Consideramos alternativas como workshops intensivos ou treinamentos obrigatórios, mas escolhemos investir na experiência do desenvolvedor e na automação de processos repetitivos.
O que foi Construído
Autenticação
Implementamos um caminho centralizado de autenticação usando OIDC/OAuth 2.0 no gateway de API. Com apenas um bloco de configuração, as equipes de produto poderiam integrar autenticação, validação de tokens e limitação de taxa sem escrever código adicional.
Tokenização
Criamos um vault centralizado para tokenização, garantindo que as equipes nunca lidassem com dados de cartão de crédito diretamente. O ciclo de vida dos tokens era gerido pela plataforma, com trilhas de auditoria embutidas para conformidade.
Onboarding no API Gateway
A publicação de proxies no gateway de API tornou-se um processo automatizado: um spec OpenAPI 3.0 gerava um PR no Terraform, que por sua vez publicava o proxy com políticas padrão de limitação de taxa, autenticação e logging.
Portal do Desenvolvedor
Com a documentação de APIs gerada automaticamente através de um pipeline CI, o portal do desenvolvedor oferecia autoatendimento completo para descoberta de APIs, solicitação de acesso e integração.
Resultado
A adoção foi um sucesso: mais de 30 equipes de produto utilizavam ao menos um golden path. A autenticação centralizada foi adotada por 95% das novas APIs, um salto significativo dos ~20% anteriores. O caminho de tokenização garantiu que 100% das APIs que lidavam com dados de cartão usassem o vault centralizado. A documentação passou de páginas no Confluence para um portal sempre atualizado.
O que Eu Faria Diferente
Se pudesse voltar no tempo, mediria a taxa de adoção desde o primeiro dia. O uso do golden path é o verdadeiro teste de sua eficácia. Além disso, documentaria claramente quando e como é aceitável se desviar do caminho, estabelecendo um "off-ramp" bem definido. Por fim, focaria em aperfeiçoar um único golden path antes de expandir para outros, garantindo qualidade excepcional em vez de quantidade.
Os golden paths que funcionam são aqueles que os desenvolvedores escolhem seguir porque eles tornam o trabalho mais fácil, não porque são obrigados a usá-los. Essa é a diferença crítica entre adoção e obrigação.