Go para Infraestrutura em Nuvem: Design Simples, Escala, Velocidade de Startup

Por que startups continuam escolhendo Go

Startups não falham porque não sabem programar — elas falham porque um time pequeno precisa entregar serviços confiáveis, resolver incidentes e manter o desenvolvimento de features ao mesmo tempo. Cada etapa de build extra, dependência confusa ou bug de concorrência difícil de depurar vira prazo perdido e páginas madrugada à frente.

Go segue aparecendo nesses cenários porque foi afinado para a realidade diária de serviços na nuvem: muitos programas pequenos, deploys frequentes e integração constante com APIs, filas e bancos de dados.

Três razões pelas quais ele se encaixa na vida de startups

Primeiro, encaixe com infraestrutura em nuvem: Go foi pensado para software em rede, então escrever serviços HTTP, CLIs e ferramentas de plataforma parece natural. Ele também produz artefatos fáceis de implantar em containers e Kubernetes.

Segundo, simplicidade: a linguagem incentiva código legível e consistente. Isso reduz o “conhecimento tribal” e acelera o onboarding quando o time cresce ou revezam o on-call.

Terceiro, escalabilidade: Go lida com alta concorrência sem frameworks exóticos e tende a se comportar de forma previsível em produção. Isso importa quando você escala tráfego antes de escalar o headcount.

Uma expectativa realista

Go brilha em serviços de backend, APIs, ferramentas de infraestrutura e sistemas que precisam de comportamento operacional claro. Pode ser menos adequado para apps com foco pesado em UI, iteração rápida de data science, ou domínios onde um ecossistema maduro e especializado é a principal vantagem.

O resto deste guia detalha onde o design do Go ajuda mais — e como decidir se é a aposta certa para o próximo serviço da sua startup.

Para que o Go foi projetado

Go não foi criado como uma “melhor linguagem de script” ou projeto acadêmico. Foi desenhado dentro do Google por engenheiros cansados de builds lentos, cadeias de dependência complexas e bases de código que se tornavam difíceis de mudar à medida que os times cresciam. O alvo era claro: serviços em rede em larga escala que precisam ser construídos, entregues e operados continuamente.

Objetivos centrais: velocidade, simplicidade e confiabilidade

Go otimiza alguns resultados práticos que importam quando você opera sistemas na nuvem no dia a dia:

• Simplicidade na linguagem, para que times compartilhem código facilmente, revejam mudanças rápido e evitem padrões “criativos” que só alguns entendem.
• Compilação rápida para manter os ciclos de feedback curtos. Quando builds são rápidos, você entrega mais, refatora mais cedo e corrige problemas antes que virem arquitetura consolidada.
• Concorrência segura como preocupação de primeira classe. Go assume que seu programa vai falar com redes, esperar I/O e atender várias requisições simultaneamente.
• Ferramentas sólidas por padrão — formatter, testes, gerenciamento de dependências e profiling — para gastar menos tempo montando toolchains e mais tempo entregando.

O que “infraestrutura em nuvem” cobre de fato

Aqui, “infraestrutura em nuvem” não é só servidores e Kubernetes. É o software que você roda e no qual seu produto depende:

• Serviços de backend e APIs (REST/gRPC) que processam requisições e lógica de negócio
• Ferramentas internas como CLIs, ferramentas de migração e serviços administrativos
• Automação para deploys, provisionamento e jobs agendados
• Componentes de plataforma como controllers, operators e malhas de serviço

Go foi criado para tornar esses tipos de programas entediantes — no bom sentido: simples de construir, previsíveis de executar e fáceis de manter conforme o código (e o time) escalam.

Simplicidade que ajuda times a andar mais rápido

O maior truque de produtividade do Go não é um framework mágico — é contenção. A linguagem mantém deliberadamente um conjunto pequeno de recursos, o que muda como times tomam decisões no dia a dia.

Menos escolhas, menos fadiga de decisão

Com uma superfície de linguagem menor, há menos debates do tipo “qual padrão devemos usar?”. Você não perde tempo discutindo metaprogramação, modelos complexos de herança ou uma dúzia de formas de expressar a mesma ideia. A maior parte do código Go converge para alguns padrões claros, o que permite aos engenheiros focar no produto e na confiabilidade em vez de discussões sobre estilo e arquitetura.

Legibilidade por convenção (e gofmt)

O código Go é propositalmente direto — e isso é uma vantagem em startups onde todo mundo mexe nos mesmos serviços. A formatação é definida por gofmt, então o código fica consistente no repositório independente de quem o escreveu.

Essa consistência paga dividendos nas reviews: diffs são mais fáceis de ler, as discussões mudam de “como isto deveria parecer?” para “isso está correto e é sustentável?”, e os times entregam mais rápido com menos atrito.

Interfaces sem cerimônia pesada

As interfaces do Go são pequenas e práticas. Você pode definir uma interface onde ela for necessária (muitas vezes próxima do consumidor), mantê-la focada em comportamento e evitar puxar uma grande framework só para obter testabilidade ou modularidade.

Isso torna refatorações menos assustadoras: implementações podem mudar sem reescrever hierarquias de classes, e é simples criar stubs em testes unitários.

Onboarding e code reviews mais baratos

Novos contratados tipicamente se tornam produtivos rápido porque o Go idiomático é previsível: fluxo de controle simples, tratamento explícito de erros e formatação consistente. Revisores gastam menos tempo decodificando “truques” e mais tempo melhorando correções, casos de borda e segurança operacional — exatamente o que importa quando o time é pequeno e a disponibilidade é crítica.

Ferramentas e velocidade de build para entregas diárias

As ferramentas do Go parecem “entediante” no melhor sentido: rápidas, previsíveis e majoritariamente iguais entre máquinas e times. Para startups que entregam diariamente, essa consistência reduz atrito tanto no desenvolvimento local quanto no CI.

Compilações rápidas = ciclos de feedback mais curtos

Go compila rápido, mesmo à medida que projetos crescem. Isso importa porque tempo de compilação faz parte de todo ciclo editar–rodar: você economiza minutos por dia por engenheiro, que se acumulam rápido.

No CI, builds mais rápidos significam filas menores e merges mais rápidos. Você pode rodar testes em cada pull request sem transformar o pipeline num gargalo, e é mais provável manter checagens de qualidade ativas em vez de “pular temporariamente”.

Testes integrados ao fluxo

go test é parte do fluxo padrão, não uma ferramenta extra a ser debatida e mantida. Ele executa testes unitários, suporta testes dirigidos por tabelas e integra-se bem ao CI.

Cobertura é direta também:

go test ./... -cover

Essa base facilita estabelecer expectativas (“testes ficam próximos ao código”, “rode go test ./... antes de subir”) sem discussões sobre frameworks.

Módulos Go para builds previsíveis

Go modules ajudam a travar dependências para que builds não mudem inesperadamente. Com go.mod e go.sum você obtém installs reprodutíveis entre laptops e agentes de CI, além de uma visão clara do que seu serviço depende.

Formatação e linting por padrão

gofmt é o guia de estilo compartilhado. Quando a formatação é automática, as reviews gastam menos tempo com whitespace e mais com design e correção.

Muitos times adicionam go vet (e opcionalmente um linter) no CI, mas mesmo a toolchain padrão já empurra projetos para uma linha de base consistente e sustentável.

Concorrência projetada para workloads de serviço

O modelo de concorrência do Go é uma grande razão pela qual ele se sente “em casa” em backends de nuvem. A maior parte do tempo dos serviços é de espera: por requisições HTTP, por uma consulta ao banco, por uma fila ou por outra chamada de API. Go foi construído para manter o trabalho fluindo durante essas esperas.

Goroutines: workers leves

Uma goroutine é uma função rodando concorrentemente com outro trabalho. Pense nela como subir um worker minúsculo para tratar uma requisição, executar uma tarefa agendada ou esperar por uma chamada externa — sem gerenciar threads manualmente.

Na prática, isso torna padrões comuns em nuvem simples:

• Atender muitas requisições ao mesmo tempo (cada handler pode disparar I/O concorrente)
• Jobs em background (envio de e-mails, geração de relatórios, refresh de cache)
• Fan-out / fan-in (chamar 5 serviços em paralelo e então combinar resultados)

Channels: jeito simples de passar resultados

Channels são canais tipados para enviar valores entre goroutines. São úteis quando você quer coordenar trabalho com segurança: uma goroutine produz resultados, outra consome, e você evita problemas de memória compartilhada.

Um exemplo típico é fan-out/fan-in: iniciar goroutines para consultar um banco e duas APIs externas, enviar resultados em um channel e agregá-los quando chegarem.

Por que isso se encaixa em serviços I/O-heavy

Para APIs, filas e apps bancados por DB, concorrência é menos sobre CPU bruta e mais sobre não bloquear todo o serviço enquanto espera por rede e disco. A biblioteca padrão e o runtime do Go tornam “esperar eficientemente” o comportamento padrão.

Orientação prática: mantenha simples

Use goroutines livremente, mas seja seletivo com channels. Muitos serviços vão bem com:

• Uma goroutine por requisição
• Um pequeno pool de workers para tarefas em background
• Channels apenas onde a coordenação for mais clara do que um mutex ou chamadas simples de função

Se channels começarem a parecer um framework customizado, geralmente é sinal para simplificar.

Desempenho e operações previsíveis

Go tende a entregar “desempenho suficiente” para startups porque acerta o ponto ideal: tratamento rápido de requisições, uso de memória razoável e comportamento previsível sob carga — sem forçar o time a ajustes de baixo nível constantes.

Como é “desempenho suficiente”

Para a maioria dos serviços em estágio inicial, o objetivo não é extrair os últimos 5% de throughput. É manter p95/p99 de latência estáveis, evitar picos inesperados de CPU e manter folga conforme o tráfego cresce. Binários compilados do Go e a biblioteca padrão eficiente frequentemente dão uma base de desempenho forte para APIs, workers e ferramentas internas.

Garbage collector e latência

Go tem garbage collection, o runtime periodicamente recupera memória não usada. O GC moderno do Go é projetado para manter pausas pequenas, mas ainda assim influencia a latência de cauda quando as taxas de alocação são altas.

Se seu serviço for sensível à latência (pagamentos, features em tempo real), você vai se preocupar com:

• Taxa de alocação (quantas vezes você cria objetos de curta duração)
• Crescimento do heap (quanto da memória permanece ativa)
• Latência p99 durante rajadas de tráfego

A boa notícia: o comportamento do GC do Go costuma ser consistente e mensurável, o que facilita operações previsíveis.

Quando perfilar, alocar menos e benchmarkar

Não otimize por sensação. Comece a se preocupar quando houver sinais claros: p99 elevado, memória crescente, saturação de CPU ou autoscaling frequente.

Go torna isso prático com profiling embutido (pprof) e benchmarking. Ganhos típicos incluem reusar buffers, evitar conversões desnecessárias e reduzir alocações por requisição — mudanças que melhoram custo e confiabilidade.

Trocas vs linguagens com runtime pesado ou mais lentas no startup

Comparado a stacks com runtime pesado, Go geralmente tem overhead de memória menor e debugging de desempenho mais direto. Comparado a ecossistemas que demoram para iniciar, o tempo de startup e o deploy de binários do Go são muitas vezes mais simples para containers e scaling on-demand.

A troca é que você precisa respeitar o runtime: escrever código consciente de alocações quando necessário e aceitar que o GC torna a latência perfeitamente determinística mais difícil do que em sistemas de memória manual.

Deploy que combina com a realidade da nuvem

A história de deploy do Go casa com a forma como startups entregam hoje: containers, múltiplos ambientes e mistura de arquiteturas de CPU. O grande diferencial é que Go pode produzir um único binário estático contendo a aplicação e a maior parte do que ela precisa para rodar.

Binários estáticos = imagens mais simples

Um serviço típico em Go pode ser construído como um único executável. Isso muitas vezes significa imagens de container extremamente pequenas — às vezes só o binário mais certificados CA. Imagens menores puxam mais rápido no CI e nos nós do Kubernetes, têm menos partes móveis e reduzem a superfície para problemas com pacotes do sistema.

Cross-compilation e multi-arch sem drama

Plataformas modernas raramente são “apenas amd64”. Muitos times rodam uma mistura de amd64 e arm64 (por custo ou disponibilidade). Go facilita cross-compilation, o que ajuda a construir e publicar imagens multi-arch do mesmo código e pipeline de CI.

Por exemplo, um passo de build pode definir explicitamente OS/architecture alvo, e a construção do container empacota o binário certo por plataforma. Isso é útil quando você padroniza deploys entre laptops, runners de CI e nós de produção.

Pegada operacional reduzida

Como serviços Go normalmente não dependem de um runtime externo (como uma VM específica ou versão de interpretador), há menos dependências de runtime para manter sincronizadas. Menos dependências também significam menos “falhas misteriosas” causadas por bibliotecas do sistema faltantes ou imagens base inconsistentes.

Menos problemas de “funciona na minha máquina”

Quando o que você entrega é o mesmo binário que você testou, o drift de ambiente diminui. Times gastam menos tempo depurando diferenças entre dev, staging e produção — e mais tempo entregando features com confiança.

Rede e HTTP: um encaixe natural

A relação do Go com infraestrutura em nuvem começa com um fato simples: a maioria dos sistemas na nuvem se comunica por HTTP. Go trata isso como um caso de uso de primeira classe, não como algo posterior.

A biblioteca padrão já é um “framework”

Com net/http você pode construir serviços prontos para produção usando primitivas estáveis por anos: servidores, handlers, roteamento via ServeMux, cookies, TLS e auxiliares como httptest para testes.

Também há pacotes práticos que reduzem dependências:

• encoding/json para APIs
• net/url e net para networking de baixo nível
• compress/gzip para compressão de resposta
• httputil para reverse proxies e debugging

APIs sem frameworks pesados (e quando frameworks ajudam)

Muitos times começam com net/http puro mais um roteador leve (frequentemente chi) quando precisam de rotas mais claras, parâmetros de URL ou middleware agrupado.

Frameworks como Gin ou Echo podem acelerar desenvolvimento inicial com conveniências (binding, validação, APIs de middleware mais agradáveis). São úteis quando o time prefere uma estrutura mais opinativa, mas não são necessários para entregar uma API limpa e sustentável.

Context, cancelamento e timeouts = higiene de nuvem

Em ambientes de nuvem, requisições falham, clientes desconectam e serviços upstream travam. O context do Go torna natural propagar deadlines e cancelamento através dos handlers e chamadas externas.

func handler(w http.ResponseWriter, r *http.Request) {
  ctx := r.Context()
  req, _ := http.NewRequestWithContext(ctx, "GET", "https://api.example.com", nil)

  client := &http.Client{Timeout: 2 * time.Second}
  resp, err := client.Do(req)
  if err != nil { http.Error(w, "upstream error", 502); return }
  defer resp.Body.Close()
}

Padrões práticos que times reutilizam

Uma configuração típica é: router → middleware → handlers.

Middleware lida com request IDs, logging estruturado, timeouts, auth e métricas. Manter essas preocupações nas bordas facilita a leitura dos handlers — e torna as falhas mais fáceis de diagnosticar quando o serviço está sob tráfego real.

Observabilidade e confiabilidade em escala

Startups muitas vezes adiam observabilidade até algo quebrar. O problema é que sistemas iniciais mudam rápido, e falhas raramente são reproduzíveis. Ter logs básicos, métricas e traces desde o dia um transforma “achamos que está lento” em “este endpoint regrediu após o último deploy e as chamadas ao DB dobraram”.

Logs, métricas, traces: um conjunto mínimo e útil

Em Go é fácil padronizar logs estruturados (JSON) e adicionar algumas métricas de alto sinal: taxa de requisições, taxa de erros, percentis de latência e saturação (CPU, memória, goroutines). Traces acrescentam o “porquê” mostrando onde o tempo é gasto entre serviços.

O ecossistema Go torna isso prático sem frameworks pesados. OpenTelemetry tem suporte Go robusto, e a maioria das ferramentas em nuvem (e stacks self-hosted) consegue ingerir esses dados. Uma configuração típica é: logging estruturado + métricas no estilo Prometheus + tracing distribuído, todos encadeados no mesmo contexto de requisição.

Profiling com pprof (respostas acionáveis)

O pprof embutido do Go ajuda a responder perguntas como:

• “Por que a CPU subiu após o release?”
• “Estamos alocando demais por requisição?”
• “Há vazamento de goroutines?”

Muitas vezes você diagnostica problemas em minutos, antes de recorrer a grandes mudanças arquiteturais.

Hábitos de confiabilidade que escalam com você

Go incentiva disciplina operacional: timeouts explícitos, cancelamento via context e shutdown previsível. Esses hábitos evitam falhas em cascata e tornam deploys mais seguros.

srv := &http.Server{Addr: ":8080", Handler: h, ReadHeaderTimeout: 5 * time.Second}

go func() { _ = srv.ListenAndServe() }()

<-ctx.Done() // from signal handling
shutdownCtx, cancel := context.WithTimeout(context.Background(), 10*time.Second)
defer cancel()
_ = srv.Shutdown(shutdownCtx)

Combine isso com retries com jitter limitados, backpressure (limitar filas, rejeitar cedo) e padrões sensatos em chamadas externas, e você obtém serviços que se mantêm estáveis conforme o tráfego e o tamanho do time crescem.

Escalando a base de código e o time

O primeiro serviço Go de uma startup costuma ser escrito por uma ou duas pessoas que “sabem onde tudo está”. O verdadeiro teste vem lá pelo mês 18: mais serviços, mais engenheiros, mais opiniões e menos tempo para explicar cada decisão. Go escala bem porque incentiva estrutura consistente, dependências estáveis e convenções compartilhadas.

Mantenha serviços pequenos e fáceis de manter

O modelo de pacotes do Go recompensa limites claros. Uma linha de base prática é:

• /cmd/<service> para o ponto de entrada principal
• /internal/... para código que você não quer que outros módulos importem
• Pacotes pequenos nomeados pela função (storage, billing, auth), não por quem os possui

Isso incentiva “poucas interfaces públicas, muitos detalhes privados”. Times podem refatorar internals sem criar breaking changes para a empresa.

Versionamento e compatibilidade ao longo do tempo

Go torna o gerenciamento de mudanças menos caótico de duas formas:

Primeiro, a promessa de compatibilidade do Go 1 significa que a linguagem e a biblioteca padrão evitam breaking changes, então upgrades geralmente são monótonos (uma coisa boa).

Segundo, Go modules tornam o versionamento de dependências explícito. Quando você precisa de uma mudança breaking na sua própria lib, o Go suporta versionamento semântico de import (/v2, /v3), permitindo que versões antigas e novas coexistam durante migrações em vez de forçar um rewrite coordenado.

Geração de código onde ajuda de verdade

Times Go costumam evitar “mágica”, mas geração seletiva de código reduz trabalho repetitivo e previne divergência:

• Protobuf/OpenAPI clients: gerar clients tipados para chamadas entre serviços serem consistentes.
• Mocks: gerar mocks de interfaces para testes unitários, mantendo os testes legíveis sem stubs feitos à mão.
• Modelos de API tipados: gerar tipos de request/response para capturar incompatibilidades em tempo de compilação.

O ponto é manter código gerado claramente separado (por exemplo em /internal/gen) e tratar o schema fonte como o artefato real.

Contratação e velocidade de onboarding

As convenções do Go fazem muito trabalho de gestão por você. Com gofmt, nomes idiomáticos e layouts de projeto comuns, novos contratados conseguem contribuir rápido porque “como escrevemos Go” é semelhante entre times. Reviews se deslocam de debates de estilo para design de sistema e correção — exatamente onde você quer atenção sênior.

Quando Go pode não ser a melhor ferramenta

Go é um padrão forte para serviços backend e infraestrutura, mas não é resposta para tudo. A forma mais rápida de evitar arrependimentos é ser honesto sobre o que você vai construir nos próximos 3–6 meses — e no que seu time realmente é bom em entregar.

Situações em que Go pode parecer mais lento

Se seu trabalho inicial é dominado por iteração rápida em UI e fluxos de usuário, Go pode não ser o lugar mais eficiente para gastar tempo. Go brilha em serviços e infraestrutura, mas prototipagem UI rápida costuma ser mais fácil em ecossistemas centrados em JavaScript/TypeScript, ou em plataformas com frameworks de UI maduros.

De forma semelhante, se seu core é data science, notebooks e análise exploratória, o ecossistema do Go vai parecer mais enxuto. Dá para fazer trabalho de dados em Go, mas Python costuma vencer em velocidade de experimentação, bibliotecas e padrões de colaboração em times de ML.

Trocas que você deve esperar

A simplicidade do Go é real, mas tem pontos de fricção que importam no dia a dia:

• Generics são poderosos, mas exigem ajuste. Se seu time aprendeu Go antes dos generics ou vem de linguagens dinâmicas, há curva para decidir quando usar generics vs manter código concreto.
• Tratamento de erros é explícito e pode parecer verboso. O lado positivo é clareza e fluxo de controle previsível; o negativo é mais código ao redor de falhas, especialmente em serviços I/O-heavy.
• Menos frameworks “baterias inclusas”. Go tende a empurrar você a compor bibliotecas pequenas em vez de adotar um grande framework “faz tudo”. Isso é ótimo para manutenção a longo prazo, mas pode atrasar times que querem convenções e scaffolding prontos.

Quando outras linguagens podem vencer

Escolher uma linguagem é sobre encaixe, não “melhor”. Alguns casos comuns:

• Python: quando o maior risco é descobrir o que construir (experimentos, protótipos, features dirigidas por dados) e você precisa iterar rápido com tooling de ML/data existente.
• Java (ou Kotlin): quando você integra profundamente em um ambiente enterprise já baseado em JVM, com bibliotecas estabelecidas e padrões operacionais que seu time deve seguir.

Checklist simples de decisão

Antes de adotar Go como sua stack principal, verifique estas perguntas:

1. Você está construindo principalmente serviços backend, APIs ou componentes de infraestrutura?
2. Seu time valoriza código simples e explícito mais do que abstrações de alto nível?
3. Você se beneficiaria de binários estáticos e deploys diretos (containers, Kubernetes)?
4. Performance e latência previsível são requisitos importantes do produto?
5. Dependências críticas têm bom suporte em Go (SDKs, bancos, filas, serviços cloud)?

Se você responder “não” a várias dessas e “sim” a prototipagem UI ou iteração voltada a data science, Go ainda pode fazer parte do sistema, mas não precisa ser o centro.

Começando: um stack Go prático para startups

Um stack Go não precisa ser sofisticado para ser eficaz. O objetivo é entregar serviço confiável rápido, manter a base de código legível e só adicionar complexidade quando o produto provar que precisa.

Arquitetura inicial que não vai te travar

Comece com um serviço deployável (um repo, um binário, um banco) e trate “microservices” como otimização posterior.

• Serviço único primeiro: uma API + jobs em background no mesmo código (pacotes separados), um deploy.
• Separe quando necessário: quebre um serviço quando houver limites claros de propriedade, necessidades de escala ou cadências de deploy conflitantes.

Blocos de construção comuns (padrões simples)

Escolha bibliotecas estáveis e aborde-as cedo.

• Router: net/http com chi ou gorilla/mux (ou um framework mínimo se o time preferir).
• Config: variáveis de ambiente + um carregador pequeno (ex.: viper ou um pacote de config leve).
• Logging: logs estruturados via zap ou zerolog.
• Acesso ao banco: database/sql + sqlc (queries tipadas) ou gorm se precisar iterar mais rápido.
• Migrations: golang-migrate/migrate ou goose.

CI/CD essenciais para entregas diárias

Mantenha o pipeline rígido, mas rápido.

• Rode go test ./..., golangci-lint e gofmt (ou goimports) em cada PR.
• Construa um artefato versionado (imagem de container ou binário) e armazene no registry.
• Adicione um smoke test básico pós-deploy (endpoint de health + checagem de uma dependência crítica).

Onde o Koder.ai entra (quando você quer entregar o produto todo mais rápido)

Se sua startup está construindo mais que “apenas um serviço Go” — por exemplo, uma API backend mais um painel web — Koder.ai pode acelerar. É uma plataforma vibe-coding que permite construir apps web, servidores e mobile a partir de uma interface de chat, usando arquitetura baseada em agentes por baixo dos panos.

Para times que padronizam em Go, ele mapeia bem para defaults comuns de startup: backend Go + PostgreSQL, e um React para web (com opção de Flutter para mobile). Você pode iterar em “modo planejamento”, fazer deploy/hosting, usar domínios customizados e contar com snapshots/rollback para reduzir risco em deploys frequentes — exatamente o fluxo operacional que times Go tendem a valorizar.

Plano de adoção de 30–60–90 dias

30 dias: layout padrão do projeto, convenções de logging, um pipeline de deploy e um doc “como escrevemos Go”.

60 dias: adicionar testes de integração, migrations no CI e runbooks básicos de on-call (como debugar, rollback e leitura de logs).

90 dias: introduzir boundaries entre serviços apenas quando comprovado, além de budgets de performance (timeouts, limites de pool do DB e testes de carga em staging).