Microsserviço virou desculpa. O monolito que funcionava virou inimigo. A discussão técnica tá circular, e o board cobra roadmap, não filosofia. É essa conversa que destravo.
O monolito tá travando o crescimento. Time discute "vamos pra microsserviços" sem evidência, sem desenho de bounded context, sem plano de migração. A decisão fica em aberto, ninguém quer assinar, e o produto para de evoluir.
Sistema event-driven foi montado em cima de RabbitMQ artesanal. Ninguém entende ordem de mensagens, idempotência, retry com backoff. Quando algo falha em produção, a investigação leva dias porque trace cruza cinco serviços sem correlação.
Latência P99 estourou SLA. A primeira reação foi cache em tudo, depois Redis, depois pré-warm. O problema continua, ninguém mediu, e o custo de infra dobrou.
Vai começar produto novo e a decisão de stack é política. Cada engenheiro tem favorito (Go, Node, Rust, Kotlin). Você precisa de leitura técnica honesta que defenda escolha com tradeoff explícito, não preferência pessoal.
Decisões arquiteturais defensáveis, com tradeoff documentado
Mapeamento de bounded contexts, dependências, pontos de acoplamento, gargalos de performance e dívida técnica priorizada por impacto. Saio com leitura escrita, não slide.
Strangler fig em etapas, por bounded context. Plano com sequência de extrações, métricas de sucesso por fase, fallback claro e critério explícito de parada.
Kafka, EventBridge ou NATS, com padrões de outbox, idempotência, ordem de mensagens, schema registry e observabilidade ponta a ponta.
Profiling em produção, análise de queries lentas, redesenho de índices, caching estratégico (não em tudo) e plano com ganho mensurável antes de codar.
Matriz de avaliação técnica (Go, Rust, Node, Java, Kotlin), com custo de contratação, maturidade de ecossistema, performance real e adequação ao caso de uso.
Architecture Decision Records pras decisões críticas, padrões de engenharia documentados, golden path pra serviços novos. Conhecimento que sobrevive ao turnover.
Padrões que aparecem com mais frequência na fila
O primeiro passo é uma conversa de 30 minutos sem custo. Entendo o problema concreto, o produto, o time e a urgência. No fim digo se faz sentido seguir comigo ou se você precisa de outro perfil.
Se faz sentido, mando proposta com escopo, prazo e valor em até 48 horas. Engajamento por projeto fechado entre duas e doze semanas, ou pacote mensal pra acompanhamento contínuo de decisões arquiteturais.
Trabalho remoto, no repositório do cliente. Entrega com ADRs, código de referência, padrões documentados e handoff pro time interno. O objetivo é o cliente sair menos dependente, não mais.
As que mais aparecem no primeiro contato
Quase nunca no estágio inicial. Microsserviços resolvem problemas de organização (times independentes), escala (componentes com perfis de carga diferentes) e isolamento de falha. Startup com cinco devs raramente tem qualquer desses problemas, e paga o custo operacional sem retorno. Monolito modular bem feito leva mais longe do que se imagina.
Strangler fig pattern em etapas, com strangulação por bounded context, não por endpoint. Identifica um contexto de domínio com fronteiras claras, extrai como serviço independente, redireciona tráfego progressivamente e mantém o monolito como fallback. Big-bang de microsserviços é a pior forma de migrar e quase sempre quebra prazo e moral.
Golang entrega performance suficiente pra 95% dos casos de microsserviço, com produtividade muito maior e mercado de talento mais maduro. Rust é a escolha certa quando o caso exige controle de memória, latência sub-milissegundo ou interop com C, mas o custo de contratação e onboarding pesa. A pergunta certa não é Go ou Rust, é qual o requisito real de performance.
Não. Event sourcing é poderoso pra domínios onde a auditoria do histórico de mutações é parte do produto (financeiro, jurídico, jogos competitivos). Em CRUD operacional, adiciona complexidade de leitura, projection e versionamento de eventos sem retorno. CQRS sem event sourcing pleno é frequentemente a escolha mais sensata.
Métricas técnicas (latência, throughput, taxa de erro, frequência de deploy, lead time) e métricas de negócio (custo de mudança, tempo até primeira release nova, incidentes em produção). Migração que melhora arquitetura no diagrama mas piora deploy frequency em três meses é regressão, não evolução.
30 minutos sem custo. Saio com leitura técnica do que tá funcionando, do que tá travando e do que vale priorizar.
Agendar Diagnóstico