É difícil assistir a uma apresentação técnica de startup hoje sem ouvir a palavra "microsserviços". O termo virou sinônimo de modernidade, escalabilidade e boas práticas de engenharia. O problema: para a maioria das startups em estágio inicial, microsserviços são a escolha errada — e essa escolha tem um custo que aparece na velocidade de entrega semanas, não anos, depois.
O que microsserviços realmente são
Microsserviços é um estilo arquitetural em que uma aplicação é composta de serviços pequenos e independentes, cada um rodando seu próprio processo e se comunicando via APIs ou mensagens. Cada serviço é responsável por uma capacidade de negócio específica e pode ser desenvolvido, implantado e escalado de forma independente.
Essa definição soa atraente. O que a definição não inclui: o overhead operacional, a complexidade de comunicação distribuída, a necessidade de infraestrutura especializada, e o custo cognitivo de manter múltiplos sistemas que precisam funcionar em conjunto.
Por que Netflix, Amazon e Google fazem isso
A origem popularizada dos microsserviços vem de empresas como Netflix e Amazon, que migraram de monolitos para serviços distribuídos à medida que cresceram. A lição que muitas startups tiram: "Se funciona para eles, devo começar assim."
O raciocínio ignora o contexto. A Netflix migrou de um monolito que estava travando o crescimento com centenas de engenheiros e décadas de dívida. A Amazon tem times de plataforma dedicados a abstrair a complexidade de serviços distribuídos.
Você está com 3 a 8 engenheiros tentando validar um produto no mercado. O contexto é radicalmente diferente.
O custo real que ninguém conta
Quando uma startup de 5 engenheiros escolhe microsserviços, aqui está o que acontece na prática:
- Deploy se torna complexo imediatamente. Você precisa coordenar deploys de múltiplos serviços, versionar APIs entre eles, e garantir compatibilidade backward. O que era um deploy se torna uma operação de orquestração.
- Debugging requer rastreamento distribuído. Um bug que antes exigia um stack trace agora requer correlacionar logs de 4 serviços diferentes para entender o que aconteceu.
- Testes de integração explodem em complexidade. Garantir que os serviços funcionam juntos exige infraestrutura de teste local sofisticada ou ambientes de staging que custam.
- Toda feature nova envolve múltiplos repositórios. Uma mudança que seria uma PR vira 3 PRs coordenadas em repositórios diferentes, com dependências entre elas.
- A curva de onboarding de novos engenheiros aumenta. Entender o sistema como um todo requer entender múltiplos contextos, não um.
Quando microsserviços fazem sentido
Microsserviços resolvem problemas reais — os problemas das empresas que os criaram. Eles fazem sentido quando:
- Times independentes precisam deployar e escalar partes do sistema sem coordenação
- Partes do sistema têm requisitos de escala radicalmente diferentes (uma API de busca que precisa escalar 100x mais que o CRUD de cadastro)
- A empresa tem plataforma de infraestrutura própria capaz de absorver a complexidade operacional
- O produto está maduro o suficiente para que os limites dos domínios de negócio sejam claros
Nenhum desses critérios se aplica a uma startup de menos de 50 engenheiros que ainda está encontrando product-market fit.
O monolito modular: o meio-termo que muita gente ignora
Entre "monolito legado desorganizado" e "microsserviços distribuídos", existe uma opção que combina os benefícios de ambos: o monolito modular.
Um monolito modular é um único sistema, mas com fronteiras de domínio claras internamente. Cada módulo tem sua própria camada de dados, interfaces bem definidas, e pode ser desenvolvido quase de forma independente — mas sem a complexidade de comunicação distribuída e o overhead operacional de múltiplos serviços.
Quando o produto crescer e os limites de escala do monolito forem atingidos, extrair serviços é muito mais fácil quando o código interno já está bem organizado por domínio.
O padrão que funciona
O padrão que vejo funcionar para startups em crescimento é consistente: começar com um monolito modular bem feito, crescer até os limites naturais dele (que são maiores do que a maioria imagina), e extrair serviços cirurgicamente onde a necessidade técnica justifica.
A decisão de extrair um serviço deve vir de um problema real — não de uma preferência arquitetural ou de uma aspiração de parecer mais "enterprise". Problemas reais incluem: times que precisam deployar independentemente, componentes com requisitos de escala radicalmente diferentes, ou partes do sistema que precisam de stack técnico diferente.
Começar com microsserviços por default é trocar problemas do futuro por problemas do presente. E problemas do presente, para startups, custam mais caro.