Um registro de construção em seis partes de um sistema real, o Bullpen, uma liga de paper trading sobre dados de mercado reais, usado para testar 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 - 04Ainda não publicadaPróxima
- 05Ainda não publicadaPlanejada
- 06Ainda não publicadaPlanejada
Faltam 3 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.