Microsserviço não é fatia de monolito: o erro de arquitetura que eu paguei em produção
Na onda do hype, minha equipe pegou uma função do monolito, pôs num serviço separado e chamou de microsserviço. Ele falava com o mesmo banco, no mesmo ambiente, por HTTPS. Deu problema em produção e me custou algumas centenas de milhares de reais. Aqui eu conto o caso e as perguntas que eu faço hoje antes de separar qualquer coisa.
🎧 PREFERE OUVIR? · 12 min · Podcast Em Produção
Este artigo também é um episódio do podcast Josimar JMV | Em Produção — o mesmo vídeo, só o áudio, normalizado pra fone.
Gravei esses 11 minutos no canal @josimarjmv em 2 de junho de 2026, com uma pizza na tela pra fazer a brincadeira da fatia. Assista e leia junto. Aqui embaixo eu conto a mesma história por escrito, com mais calma, e ponho o que eu fui conferir depois.
microsserviço não é um pedaço que você corta do monolito. Um serviço separado só se justifica quando ele precisa escalar sozinho, quando outra equipe (ou um terceiro) vai cuidar dele, ou quando é um processo pesado e assíncrono. Se a função só salva no banco e avisa outro sistema, ela é uma rota do monolito. Separar traz teste, CI, ambiente, SSL, proxy, redundância, backup e monitoramento em dobro. Na minha empresa a gente separou sem precisar, bateu cabeça, matou o serviço e devolveu a função pro monolito. Nunca mais deu problema.
De onde eu falo
Vou dar minha carteirada antes. Meu nome é Josimar e eu sou de uma empresa real de tecnologia, com time real de dev. Não é empresa agêntica fictícia. O que eu trago aqui é caso real, que aconteceu comigo, em produção.
Já comentaram no canal que eu estaria expondo o time. Não estou. Eu não ponho nome de ninguém, e o meu objetivo não é expor equipe. É trazer erro que todo mundo comete. Eu já errei, minha equipe já errou, e a gente também acertou muito. Esse aqui é um dos erros, e ele me custou, pelas minhas contas de cabeça, algumas centenas de milhares de reais.
Um detalhe importante: na época desse hype eu não estava com a mão no código. Foi a fase em que eu coloquei a mochilinha nas costas e fui vender, fazer parceria, fechar contrato grande. A empresa cresceu muito rápido. A decisão de arquitetura foi da equipe da época. A conta, essa veio pra mim.
O sistema: uma playlist de vídeo que simulava transmissão 24 horas
A gente tinha um sistema de gestão de playlist de vídeo. Imagina comigo: uma dashboard onde o usuário sobe os vídeos e monta uma galeria. Só que, além da galeria, tinha uma opção em que você programava esses vídeos e eles ficavam executando 24 horas por dia, simulando uma transmissão ao vivo.
Quem fazia essa mágica era um sisteminha em Java, criado pra gente há muitos anos por um desenvolvedor que hoje trabalha no Google. Java, gente, olha pra você ver. E funcionava bacana.
O primeiro back-end era em PHP. Ele fazia toda a gestão e se comunicava com o Java. Funcionava direitinho. Até a hora em que precisou escalar.
A escala por DNS, que foi invenção nossa
A aplicação PHP não tinha nada de stateless. Pra escalar do jeito certo, ia ter que jogar fora e fazer de novo, e não deu tempo: os clientes foram chegando. Na época eu tinha um ou dois desenvolvedores in loco.
Então a gente escalou com DNS. Olha que doideira: instalações separadas da mesma aplicação, e a gente ia passando pros clientes. Tipo aplicacao01.dominio.com, aplicacao02.dominio.com. A gente ainda não tinha data center próprio, então eram servidores alugados, com o DNS apontando pra um e o fallback pra outro.
Era o que dava pra fazer no momento. E tem muita gente de streaming que trabalha assim até hoje, com painelzinho de revenda.
Só que a gente passou de milhares de clientes. Manutenção, suspensão, ativação: ficou insustentável. Aí eu trouxe uma pessoa mais sênior, que já usava Node.js naquela época, e a gente fez a aplicação de back-end de novo. Funcionou bem e começou a escalar.
O hype chegou e fatiaram o monolito
Em algum momento, que eu não lembro exatamente qual, veio o hype de microsserviço. A gente começou a separar algumas coisas. Algumas fizeram bastante sentido. Essa aqui, não.
Pensa comigo no que a função precisava fazer. O usuário entra na dashboard, arrasta os vídeos e monta a playlist. Essa playlist só precisava de duas coisas:
- ser salva no banco de dados (que era um cluster, com backup e monitoramento, tudo certo);
- avisar o Java, com um PATCH ou um POST, dependendo do que tinha acontecido. O Java fazia o update dele e respondia.
Era isso. Basicamente era isso.
Criaram um microsserviço pra essa função. A dashboard passou a mandar pra essa aplicação nova, que mandava pro Java, que se comunicava com o mesmo banco de dados, e voltava. E o pior: estavam no mesmo ambiente e ainda se comunicavam por URL, por HTTPS.
Pra que fazer isso?
Criaram um microsserviço totalmente inútil, que uma rota do próprio monolito fazia. Pegaram o monolito, fatiaram, colocaram uma função num canto e acharam que aquilo era microsserviço. É a brincadeira da pizza que eu fiz na gravação: microsserviço não é uma fatia de pizza de monolito.
Entraram no hype e não aprofundaram. Ficou na superficialidade do hypezinho de cursinho de pandemia. A equipe da época decidiu o que tinha que fazer e fez. Como eu disse, ela acertou em muita coisa. Mas esse é um erro que eu tenho certeza: quem trabalhou nisso vai levar pro resto da vida, pra nunca mais cometer.
O que vem junto quando você separa um serviço
E aí o sistema começou a dar problema. Por que carga d'água eu preciso de um pedaço do monolito separado, se comunicando por HTTPS?
A pergunta que ninguém fez na hora: esse serviço que gerenciava a playlist e falava com o Java precisava escalar sozinho? Não. Ele não tinha necessidade nenhuma de escalar sozinho. Então por que ele ia ser um serviço separado?
Porque microsserviço não é só "outro repositório". Olha a complexidade que vem atrás dele. Tudo separado:
- teste e CI;
- comunicação com o banco de dados;
- ambiente de sandbox, de staging e de produção;
- SSL, e subdomínio ou rota pra chegar nele;
- configuração no proxy;
- redundância;
- backup;
- monitoramento, e observabilidade pra saber se ele está respondendo direitinho.
E tem a condição de corrida, criatura. Dois serviços gravando no mesmo banco, cada um no seu tempo.
Banco em cluster tem as suas manhas. A gente usa cluster Galera. Num cluster desses, o ID não é gravado de um em um: se você tem cinco nós, ele anda de cinco em cinco. Se você não sabe como funciona cluster, dá uma estudada. O Fábio Akita tem um vídeo maravilhoso explicando isso. Eu não vou entrar no detalhe porque não é a minha praia.
Fui conferir essa parte na documentação. Está lá: a variável wsrep_auto_increment_control, ligada por padrão, ajusta o passo e o deslocamento do auto incremento conforme o tamanho do cluster, justamente pra evitar conflito de replicação. É o que diz a referência de variáveis do Galera Cluster na MariaDB, que eu li em 12 de outubro de 2026. Com cinco nós, o passo é cinco, e cada nó começa num ponto diferente.
Sobre saber se o serviço está respondendo, eu tenho um texto só disso: sem log você está no escuro.
"Mata e bota a rota no monolito"
Bateram cabeça um bom tempo com aquilo, até alguém dizer: "não, cara, tem que matar isso. Isso aqui não faz o menor sentido".
Ou seja: gastou-se tempo, estudou-se, trouxe-se o microsserviço, e matou-se o microsserviço.
Não foi uma conversa leve. A gente teve que chegar em discussões mais sérias dentro da empresa, e eu tive que bater o pé na mesa: mata, e bota só a função no monolito. Rota no monolito, um MVCzinho resolve.
Resolveu. Nunca mais tivemos problema.
A aplicação inteira, aliás, a gente já aposentou. Na data da gravação fazia uns dois anos.
É um caso engraçado de contar hoje. Na época me gerou muito problema.
Responsabilidade única virou microsserviço de função única
Sabe o princípio de responsabilidade única, de que a gente tanto fala? Levaram muito ao pé da letra. Responsabilidade única virou um microsserviço de função única.
Eu prefiro um princípio de administração, bem mais simples: eu preciso disso? Não precisa. Então mata.
Hoje eu acho que isso não aconteceria, com o avanço da inteligência artificial. Quem tiver o mínimo de curiosidade, e não tiver medo de perguntar, abre a IA e escreve: "o que pode dar errado nisso aqui?". Ela responde.
O que eu fui conferir: quem batizou o termo diz a mesma coisa
Depois da gravação eu fui ver o que dizem os autores que popularizaram o termo, pra saber se a bronca era só minha. Não é. Li os três textos em 12 de outubro de 2026.
- Na definição de 2014, James Lewis e Martin Fowler descrevem microsserviços como serviços pequenos, construídos em torno de capacidades de negócio e implantáveis de forma independente, que podem usar tecnologias de armazenamento diferentes. O serviço da minha história dividia o banco com o monolito e não vivia sem ele.
- Em Microservice Premium, de 2015, Fowler escreve que a diretriz principal dele é nem considerar microsserviços, a não ser que o sistema seja complexo demais pra ser gerenciado como monolito, e que a maioria dos sistemas deveria ser construída como uma aplicação monolítica única.
- Em Monolith First, também de 2015, ele conta que quase todas as histórias de sucesso que ouviu começaram com um monolito que cresceu demais e foi quebrado.
A tradução dos trechos é minha. E o nosso caso é o inverso do que funciona: o monolito não estava grande demais naquela função. Estava ótimo.
A colinha: quando faz sentido ter um microsserviço
Eu fiz uma colinha pra gravação. São as premissas que eu confiro antes de aceitar que alguma coisa vire um serviço separado.
| A pergunta | Quando a resposta justifica separar |
|---|---|
| Precisa de escala horizontal separada? | É um worker. No meu caso, conversão de vídeo: precisa escalar sozinho, então vale toda a complexidade de CI, teste, monitoramento e observabilidade atrás dele. |
| Eu tenho a stack dentro de casa pra cuidar dele? | Se não tenho, eu terceirizo aquele pedaço. Dou permissão só naquele serviço, e a pessoa testa, desenvolve e faz deploy só daquela partezinha. |
| A equipe é a mesma do projeto principal? | Liga com a de cima: quando é outra equipe, ou um terceiro, cuidando só daquele pedaço, faz sentido separar. |
| Vai afetar a performance do monolito ou da base principal? | Se ele vai pesar na base principal, é motivo pra olhar com atenção. |
| É síncrono ou assíncrono? | Se é um processo que demora, eu respondo 200 na hora, a vida segue, e acompanho a execução por status. |
| Tem exigência de compliance, governança ou contrato? | Banco é outra vibe. E eu atendo algumas áreas de governo: às vezes vem cada requisito que a gente tem que cumprir e pronto. |
Sobre terceirizar um pedaço: isso funciona bem porque eu só uso GitLab, e lá eu controlo a permissão por repositório. Os motivos estão em GitLab próprio: como eu rodo mais de 300 microsserviços sem pagar GitHub. E repara no título: eu não sou contra microsserviço. Eu sou contra microsserviço sem motivo.
Sobre escala horizontal: separar não conserta aplicação ruim. Eu trato disso em autoscale não salva aplicação mal feita.
No mercado comum, a possibilidade de você precisar de um microsserviço separado é bem pequena. E eu estou falando do mercado comum, que é, sei lá, uns 90% dos casos, talvez. É chute mesmo: eu não conheço todo o mercado que existe, tem software pra cada coisa na vida em que eu nunca mexi. Na dúvida, eu volto na pergunta: eu preciso disso?
Se essas perguntas tivessem sido feitas na minha empresa, anos atrás, antes da farra do microsserviço, a pizza estaria inteira. Pelo menos aquele pedaço estaria junto.
Pra você, vibe coder: pergunte antes de implementar
É uma lição que a gente aprendeu apanhando, e eu trouxe pra você não apanhar igual.
E você, amigo vibe coder, principalmente: entenda isso, e faça essas perguntas pra sua inteligência artificial antes de implementar. Porque se você for só na cabeça dela, você vai criar muita coisa que não precisa.
Tem mais desse tipo de cuidado em o que todo vibe coder descobre tarde demais ao subir pra produção e em criar software com IA: o erro que mata o seu SaaS, que é outro caso de separar o que devia estar junto.
Nota de cronologia
Gravei em 2 de junho de 2026 e este texto saiu em 12 de outubro de 2026. O caso é de anos antes da gravação, e eu contei de cabeça: não cravo o ano em que o serviço foi criado porque eu mesmo não lembro. O valor do prejuízo também é estimativa minha, não número de balanço.
Discorda? Concorda? Tem um caso parecido? Aqui não tem caixa de comentário de propósito: segunda-feira, ao meio-dia, eu faço live no canal e a gente conversa sobre isso ao vivo — sem corte, como sempre.
Ver as lives no canal @josimarjmv →Perguntas frequentes
Qual a diferença entre microsserviço e uma fatia do monolito?
Microsserviço de verdade tem motivo pra viver separado: precisa escalar sozinho, é cuidado por outra equipe ou roda um processo pesado fora do fluxo principal. A fatia de monolito é uma função que você tirou do lugar e pôs em outro serviço, mas que continua usando o mesmo banco, a mesma equipe e o mesmo ambiente. Foi o que fizeram na minha empresa: uma rota do próprio monolito resolvia, e criaram um serviço inteiro pra ela.
Quando faz sentido criar um microsserviço?
A primeira pergunta que eu faço é se ele precisa de escala horizontal separada. Um worker de conversão de vídeo, no meu caso, precisa. Também faz sentido quando eu não tenho a stack dentro de casa e vou terceirizar aquele pedaço: aí eu dou permissão só naquele repositório e a pessoa testa, desenvolve e faz deploy só daquela parte. Fora isso, eu olho se é outra equipe, se afeta a performance da base principal e se o processo é assíncrono.
O que vem junto quando eu separo um serviço?
Vem tudo separado: teste, CI, comunicação com o banco de dados, ambiente de sandbox, staging e produção, SSL, subdomínio ou rota, configuração no proxy, redundância, backup, monitoramento e observabilidade. E vem problema novo, como condição de corrida quando dois serviços gravam no mesmo banco.
Microsserviço pode usar o mesmo banco de dados do monolito?
No meu caso usava, e esse era um dos sinais de que aquilo não era um microsserviço. O serviço recebia a chamada da dashboard, falava com o mesmo banco de dados do monolito e avisava o serviço Java. Era a mesma função, só que com uma chamada HTTPS a mais no meio, dentro do mesmo ambiente.
Responsabilidade única quer dizer um microsserviço por função?
Não. Na minha empresa levaram o princípio de responsabilidade única muito ao pé da letra, e responsabilidade única virou um microsserviço de função única. A função que salvava a playlist cabia numa rota do monolito, num MVC simples. Foi assim que a gente resolveu no fim, e nunca mais teve problema.
Como eu sei se o meu processo deve ser assíncrono?
Eu pergunto se ele consegue executar de forma síncrona ou se realmente é um processo que demora mais. Se demora, eu respondo 200 na hora, a vida segue, e quando ele termina de executar eu acompanho por status. Esse tipo de trabalho é candidato a serviço separado. Salvar uma playlist no banco não é.
Quem programa com IA deve começar com microsserviços?
Faça as perguntas pra sua inteligência artificial antes de implementar: o que pode dar errado nisso aqui, e eu preciso disso? Se você for só na cabeça dela, você vai criar muita coisa que não precisa. No mercado comum, a chance de você precisar de um microsserviço separado é bem pequena.
Baseado na gravação do canal @josimarjmv publicada em 02/06/2026 (11min41s), com transcrição própria das legendas do próprio vídeo.
O que veio da gravação e o que é apuração minha, com as fontes
Da gravação: a empresa real de tecnologia com time real de dev; não expor a equipe; a fase em que eu fui vender e fechar contrato e não estava com a mão no código; o prejuízo de algumas centenas de milhares de reais, estimado de cabeça; o sistema de playlist de vídeo que simulava transmissão 24 horas; o serviço em Java criado por um desenvolvedor que hoje trabalha no Google; o primeiro back-end em PHP, sem nada de stateless; a escala por DNS com instalações separadas, em servidores alugados; os um ou dois desenvolvedores da época; os milhares de clientes; a reescrita com uma pessoa mais sênior em Node.js; o microsserviço criado pra salvar a playlist e avisar o Java, usando o mesmo banco e se comunicando por HTTPS no mesmo ambiente; a lista do que vem separado (teste, CI, banco, ambientes, SSL, subdomínio ou rota, proxy, redundância, backup, monitoramento, observabilidade) e a condição de corrida; o cluster Galera com ID de cinco em cinco com cinco nós e a indicação do vídeo do Fábio Akita; a decisão de matar o serviço e pôr a função numa rota do monolito; a aplicação aposentada uns dois anos antes da gravação; a responsabilidade única que virou microsserviço de função única; as perguntas da colinha (escala horizontal, terceirização com permissão por serviço no GitLab, mesma equipe ou equipe separada, performance, síncrono ou assíncrono, compliance e governo); o chute de 90% dos casos; o recado pro vibe coder. Tudo dito de cabeça, direto.
Apuração minha (12/10/2026): o ajuste automático do auto incremento conforme o tamanho do cluster está na descrição de wsrep_auto_increment_control, na referência de variáveis do Galera Cluster, na documentação da MariaDB. A definição de microsserviços como serviços implantáveis de forma independente está em Microservices, de James Lewis e Martin Fowler, de 25/03/2014. A diretriz de nem considerar microsserviços se o sistema não for complexo demais pra um monolito está em Microservice Premium, de Martin Fowler, de 13/05/2015. O padrão de sucesso começando por um monolito está em Monolith First, de Martin Fowler, de 03/06/2015. As traduções são minhas. Não localizei qual é o vídeo do Fábio Akita citado na gravação, então não ponho link. A comparação entre o meu caso e esses textos é leitura minha, feita depois da gravação.