A história de como uma startup em alta quase quebrou 6 meses após adotar MSA

Recentemente li um texto que virou assunto em blogs técnicos no exterior, "Microservices Killed Our Startup. Monoliths Would’ve Saved Us", e achei o conteúdo tão dolorosamente verdadeiro e fácil de se identificar que resolvi compartilhar um resumo.

Parece um ótimo "caderno de erros" mostrando o quão perigosa pode ser a adoção incondicional da tecnologia mais recente.

---

1. O começo do incidente: "Vamos fazer como a Netflix"

• Situação: captação seed de $2.5M, crescimento de 40% na receita mensal, 50 mil usuários. Uma startup que estava funcionando muito bem com um monólito em Rails.
• Início do problema: surge o arquiteto líder propondo a migração para MSA em nome da "escalabilidade (Scalability)".
• Lógica: "A estrutura atual está acoplada demais. Olha a Netflix e a Uber. Se quisermos chegar lá, precisamos ir para microservices."
• Realidade: decidiu-se adotar uma arquitetura no estilo Netflix em um time com 4 desenvolvedores e 1 pessoa de DevOps.

2. Seis meses de inferno (linha do tempo da adoção de MSA)

[Mês 1: lua de mel]

• Separação bem-sucedida do serviço de notificações. "Viu? Está funcionando!", comemoraram.
• Mas já começaram os sinais de alerta, como aumento do tempo de deploy e mais repositórios para manter.

[Meses 2~3: o começo das rachaduras]

• Separação do serviço de billing. O problema é que ele estava amarrado a usuários, estoque e pedidos.
• Resultado: por causa da latência de rede, o tempo de resposta caiu de 200ms → 800ms. Quando um serviço morria, surgia um efeito cascata e tudo parava.

[Meses 4~5: o pesadelo das transações distribuídas]

• O que no monólito seria resolvido com uma única transação de banco acabou exigindo até a adoção do padrão Saga em um ambiente distribuído.
• O estoque era baixado, mas o pagamento falhava, o rollback se embolava... e a inconsistência de dados fez o suporte explodir.
• Para adicionar uma única coluna simples, era preciso mexer em 6 serviços, então algo que levaria 2 horas passou a levar 3 dias.

[Mês 6: colapso do time]

• Os desenvolvedores passaram a gastar todo o tempo com infraestrutura em vez de criar funcionalidades.
• Custo de infraestrutura: $3,000 → $12,000 (aumento de 4x).
• Saída de um desenvolvedor-chave ("Eu vim para construir produto, não para passar o dia inteiro mexendo em Kubernetes")

3. A decisão: "Nós não somos a Netflix"

O arquiteto ainda insistia em "adotar Service Mesh e aumentar as ferramentas de monitoramento", mas o autor explode.

> "Nós não somos a Netflix! A Netflix tem 500 engenheiros, nós somos 4!"

No fim, o arquiteto saiu da empresa, e o time decidiu fazer rollback para o monólito.

4. De volta ao monólito, e a recuperação

• Ao longo de 8 semanas, o código foi reunificado em um monólito novamente.
• Resultado:
• recuperação da velocidade de entrega de funcionalidades (4 por mês → 20 por mês)
• tempo de resposta estabilizado em 220ms
• redução dos custos de infraestrutura
• e, acima de tudo, mais felicidade para os desenvolvedores

5. Lições principais (a conclusão do texto)

1. MSA é uma ferramenta para resolver um problema 'organizacional', não um problema 'técnico'.

• Ela deve ser usada quando há mais de 50 desenvolvedores pisando uns nos outros, ou quando os ciclos de deploy são muito diferentes entre si.

2. Netflix/Google não são seus modelos a serem copiados.

• Eles também começaram com monólitos. Mudaram quando cresceram; não começaram assim desde o início.

3. Complexidade é imposto.

• Cada novo serviço faz o custo de gerenciamento crescer de forma composta.

4. Chamadas de rede não são grátis.

• Uma chamada de função em memória (nanosegundos) e uma chamada de rede (milissegundos) estão em ordens de grandeza completamente diferentes.

---

Resumo em uma frase:
"O monólito não é o inimigo. A má arquitetura é que é. Um time de 4 pessoas, por favor, simplesmente use um monólito."

[ahwjdekf]

Pronto. Agora os fanáticos por MSA já vão aparecer.

[aer0700]

Dizer que chamadas de rede não são gratuitas está certíssimo. Chamar uma função e fazer uma chamada de API são claramente coisas diferentes.

[bungker]

Eu vim para criar produtos, não para passar o dia inteiro mexendo em Kubernetes —> essa é a coisa mais idiota que já ouvi

[hohemian]

Por quê? Acho que isso faz sentido numa situação em que estão usando k8s tendo k8s como objetivo em si.

[roxie]

Como gosto dos comentários do bungker, vou clicando em cada um deles, mas nesse aqui especificamente não consegui concordar, hum. Você poderia explicar melhor?

[passerby]

Postagem sobre IA sem conteúdo nenhum; é por isso que hoje em dia quase não leio o Medium.

[mhj5730]

Se é um serviço feito por 4 pessoas, realmente parece que não haveria motivo para dividir em MSA.

[moderato]

Para fazer MSA, a organização também precisa se alinhar ao MSA...

[ifmkl]

Acho que o ponto que o item 4 quer transmitir deve estar no resumo abaixo. E, no geral, concordo bastante com o conteúdo em si.

[bsh998]

Hum... acho que tem algo estranho aqui.
Parece que este texto foi escrito por IA.

[baeba]

Eu também tenho sentido muito isso ultimamente..
Acho que muitos textos de blogs não estão sendo escritos com base na própria experiência da pessoa + ajuda de IA.
Os textos são lógicos demais e escritos de um jeito muito fácil de ler.

[bsh998]

O que eu queria dizer é que este texto parece muito gerado por IA e não tem referências, então acho melhor não compartilharem esse tipo de conteúdo.

[baeba]

É um texto publicado no Hacker News. A maioria dos textos que eu posto é de conteúdo publicado no Hacker News.

https://news.ycombinator.com/item?id=46469845

Como você mencionou... acho que realmente preciso incluir a referência ao Hacker News.

[baeba]

1) Dúvidas sobre a credibilidade do texto: tem cheiro de marketing/conteúdo gerado por IA

Resumo

• “Isso está arrumadinho demais, quase como uma peça com moral da história” → gerou suspeita de que o texto foi otimizado para o tipo de ‘conto moral’ que o HN gosta
• O corpo do texto está cheio de links para material pago, então muita gente reagiu com “no fim das contas isso não é só um texto de vendas?”
• O estilo com listas em excesso/emojis foi apontado como sinal de “AI slop” (conteúdo de IA feito nas coxas)

Citação contundente (tradução)

“Parece que o texto inteiro existe só para te vender os materiais linkados. E passa uma vibe de AI slop com todas essas listas.”
(original: Seems like the whole thing is just there to sell you on the linked resources. And it feels like AI slop with all the lists.)

Resumo em uma linha

• “Antes mesmo de discutir se o conteúdo está certo ou errado, o cheiro de venda + cheiro de IA está forte demais” foi a reação nº 1.

---

2) Críticas à liderança/arquitetura: o problema não era técnico, era a ‘estrutura de decisão’

Resumo

• Muita gente reagiu com “arquiteto em um time de 4 pessoas?” como sinal de que já começou torto
• Em especial, houve muita crítica ao arquiteto que não programa / função de DevOps separada, vistos como “gargalo + otimização de currículo”
• O tom era de que o que quase afundou a empresa não foi microservices, e sim uma estrutura em que “ninguém assume de fato deploy/operação/incêndio”

Citação afiada (tradução)

“Arquitetos cujo trabalho é definir ‘regras’ e ‘padrões’ sem de fato implementar nada quase sempre são uma péssima ideia. Foquem em entregar logo... Quem não vai escrever nem 10 linhas de código não pode monopolizar as decisões.”
(original: Architects who's job it is to define 'rules' and 'patterns' without actually implementing anything are almost always a bad idea. Just focus on shipping...)

Resumo em uma linha

• Foi forte a visão de que o problema não era MSA, e sim um desenho de papéis com poder de decisão, mas sem responsabilidade.

---

3) Perspectiva de negócio: a startup realmente quase morreu por causa de MSA?

Resumo

• Houve comentários que simplesmente não compraram a narrativa de “quase morremos por causa da arquitetura”
• Ponto central: se PMF/demanda/lock-in de clientes são fracos, qualquer stack vai fracassar
• Em especial, detalhes como “o cliente vai embora só porque ficou dois dias mais lento?” foram usados para questionar se o valor do produto já não era fraco desde o início
• Também apontaram contradições internas do texto: “MSA matou a startup” mas no fim “ela sobreviveu?” → suspeita de dramatização da narrativa

Citação contundente (tradução)

“Tenho quase certeza de que o que matou a startup foi fazer um produto que as pessoas não queriam. Isso é tão sem sentido quanto dizer que Python vs Go matou a startup...”
(original: Pretty sure making a product that people don’t want killed your startup. This is like saying using Python vs Go killed your startup...)

Resumo em uma linha

• Existe claramente a visão de que arquitetura é desculpa, e que a causa real pode ter sido mercado/produto/fluxo de caixa.

---

4) Insight técnico: conselhos práticos baseados em experiência sobre monólito vs MSA (a parte realmente útil)

Resumo

• “MSA cobra um imposto fixo de complexidade operacional” → vários relatos dizem que isso pode ser fatal para times pequenos
• Palavras-chave centrais: Premature distribution (distribuição cedo demais), monólito modular/modulith, “ganhe seus limites (boundaries)”
• Também apareceram condições realistas para quando MSA faz sentido: quando o time cresce e problemas reais de conflito/deploy/organização começam a aparecer
• Por outro lado, houve o conselho de que problemas de performance/escala geralmente não se resolvem com “vamos para MSA”, e que o melhor é olhar primeiro para algoritmo/gargalos/sharding/partitioning

Citação afiada (tradução)

“O que quase matou a startup não foram microservices, e sim a ‘distribuição cedo demais’. Vocês dividiram antes de existirem limites reais e só pagaram o custo de latência/coordenação. Comecem com um monólito modular, ganhem seus limites e só então extraiam.”
(original: Premature distribution killed the startup, not microservices... Start with a modular monolith, earn your boundaries, then extract.)

Resumo em uma linha

• A lição com que a comunidade realmente concordou foi esta:
  “Comece com um monólito e só separe serviços quando os limites surgirem de forma ‘natural’.”

---

Avaliação geral da comunidade em uma frase

A maioria concordou com “nós não somos a Netflix”, mas ao mesmo tempo houve forte suspeita de que o próprio texto possa ser uma narrativa vendendo a doença de querer ser a Netflix (= marketing/IA).