Um registro de construção em seis partes de um sistema real, o Bullpen, uma liga de paper trading sobre dados de mercado reais, mais um bônus sobre um requisito que chegou no meio do plano. Ele testa quais decisões de microsserviços e sistemas distribuídos ainda se sustentam em 2026, custo incluído. Ele registra minha visão neste momento: as plataformas por baixo mudam todo mês, e parte disso vai envelhecer.
Estou construindo um sistema distribuído real em público e fazendo cada split merecer seu lugar com um teste, uma medição ou uma fatura. Este é um retrato datado de como eu arquitetaria software em 2026, não um manual atemporal.
As partes
- 01Quando usar microsserviços em 2026: escalar, por si só, já não é o motivo
No dia em que o Dow registrou uma alta recorde para a época, os clientes da Robinhood não conseguiram operar da abertura ao fechamento. Separar a parte quente para que ela escale sozinha era a resposta antiga; hoje uma plataforma serverless faz isso por função. Abro esta série com o Bullpen, uma liga de paper trading sobre dados de mercado ao vivo, e defendo quando usar microsserviços em 2026: só por um motivo que eu consiga nomear, com um teste, uma medição ou uma fatura por trás.
Engineering4 de out. · 13 min de leitura - 02Arquitetura como código tem três funções: descrever, governar, lembrar
Na primeira semana do Bullpen, o modelo de arquitetura planejado ainda citava um provedor de ações que eu tinha recusado, e uma mudança no rodapé e um teste o seguiram. Nada falhou. Uso esse incidente e outros dois para defender que arquitetura como código tem três funções: descrever o sistema, governá-lo e lembrar por que ele tem a forma que tem. Depois sigo a primeira mudança real após as correções, o analytics de produto, pelas três: um registro de decisão antes que o modelo pudesse citá-lo, arquitetura construída e planejada que discordavam, e uma regra que compõe as duas em vez de editar qualquer uma delas.
Engineering11 de out. · 12 min de leitura - 03Database per service agora é de graça. Isso não é motivo para usar
Um free tier que dobra muda as entradas de uma decisão, não a decisão. Na primeira semana, previ que o Bullpen dividiria preços e histórico em dois serviços com dois bancos de dados. Depois o Neon fez database per service parecer de graça, e eu precisei decidir se isso mudava alguma coisa. Este é o histórico de decisões: cinco decisões de dados e deploy, cada uma com suas condições, as opções que pesei, por que uma venceu e o que me faria voltar atrás.
Engineering19 de out. · 30 min de leitura - 04O padrão Saga é sobre tempo, não sobre serviços
O padrão Saga nasceu como solução para transações que duram demais. Uma ordem que vive mais que uma transação precisa de uma saga, mas não de outro serviço. Na Parte 4, o Bullpen começa a aceitar ordens: reservar poder de compra, receber execuções parciais, disputar um cancelamento, liquidar e liberar o que sobrou. Este é o histórico de decisões de onde esse ciclo de vida roda, de como uma execução que chega depois de um cancelamento é registrada e do que eu quebrei de propósito para provar que o ledger continua certo.
Engineering26 de out. · 23 min de leitura - 05Todo novo requisito tem um custo. Torne-o visível.
O ranking do Bullpen precisava de usernames, e usernames precisam de moderação. Em vez de recusar um requisito que o plano nunca teve, levantei o custo de quatro respostas, de "agora não" ao Jev, da TypeSafe, no Vercel AI Gateway com uma fila de revisão, e deixei o custo decidir. Este bônus entre a Parte 4 e a Parte 5 mostra as opções, o escopo, as regras que mantêm a mudança dentro dele e o que o modelo mediu.
Engineering10 de nov. · 19 min de leitura - 06Ainda não publicadaPróxima
- 07Ainda não publicadaPlanejada
Faltam 2 partes. Novas partes saem às segundas-feiras, 9h (horário do Pacífico) — deixe seu e-mail e eu envio cada uma no dia em que sair. Só isso.