A Zona de Transição: O Backend Está Se Tornando Software Que Dorme

Rodar software custa dinheiro. Ponto final. Toda arquitetura que já coloquei em produção é, por baixo dos diagramas, uma resposta a uma única pergunta: estou pagando para software esperar, ou pagando para software trabalhar?

Por vinte anos minha resposta foi "esperar". Um arquivo WAR em um servidor Java EE atrás do Tomcat espera. Uma frota de microsserviços Spring Boot no Kubernetes espera. A JVM fica aquecida, o heap fica alocado, o load balancer faz health-check de um processo cujo trabalho principal, na maior parte do dia, é estar pronto. Eu fiz capacity planning dessa espera, autoescalei, dimensionei e paguei por ela no primeiro dia de cada mês independentemente do que os usuários fizeram.

Também já vi a indústria tentar parar de pagar por isso duas vezes antes. As duas tentativas emperraram na mesma pedra: estado. E a razão pela qual estou escrevendo este post — a razão pela qual ele abre uma série de pesquisa em vez de encerrar um argumento — é que passei meses lendo changelogs, páginas de preço e anúncios de frameworks, e continuo chegando à mesma conclusão. A pedra foi removida. Está acontecendo de novo, e desta vez o déjà vu vem com datas e preços anexados.

Três ondas, uma fratura recorrente

O arco que vivi é o arco que a maioria dos engenheiros de backend da minha geração viveu, então vou comprimi-lo — mas quero nomear o que cada onda quebrou, porque a quebra é o padrão.

A primeira onda foi o monólito, e ele era melhor do que sua reputação. Um deployable em um servidor de aplicação, um banco de dados relacional, uma fronteira de transação. Estado não era um problema naquele mundo — era a competência central do produto. BEGIN, mutação, COMMIT; o banco de dados impunha cada invariante, e um rollback apagava cada erro. O que o monólito custava era agilidade e raio de impacto: uma base de código, um trem de releases, um domínio de falha. E ele rodava sobre capacidade comprada antecipadamente — servidores dimensionados para o tráfego que você esperava ter.

A segunda onda me atingiu por volta de 2016, embora seus textos fundadores sejam anteriores — James Lewis e Martin Fowler publicaram o artigo sobre microsserviços em março de 2014, e a stack Netflix OSS somada ao Spring Cloud transformaram isso em algo que um engenheiro Java conseguia de fato montar. Quebrar as plataformas gigantes em pedaços menores comprou deploy independente e autonomia de time, e quebrou o estado — pela primeira vez. A transação que antes abrangia um banco de dados agora abrangia uma rede. Já escrevi em detalhe sobre as cicatrizes que isso deixou: a janela de bloqueio do commit em duas fases que ninguém coloca no diagrama, o outbox transacional que todo mundo trata como uma fila até o Postgres ceder, a idempotência como um protocolo de quatro partes porque as retentativas transformaram cada escrita em uma possível duplicata. Nenhum desses padrões existia nos meus anos de monólito porque nenhum deles era necessário. Eles são as primitivas de estado que a segunda onda teve de inventar antes que pudesse ser confiável com dinheiro.

Repare no que a segunda onda não mudou: a unidade era menor, mas ainda esperava. O Kubernetes — de código aberto em 2014, 1.0 em 2015 — industrializou a espera. Ele tornou frotas de processos de longa duração agendáveis, reiniciáveis e observáveis, e deixou a economia intocada: um pod é um processo que roda quer alguém o chame ou não.

A terceira onda começou na mesma temporada — o AWS Lambda foi lançado em novembro de 2014 — e mirou diretamente na espera. Encolher a unidade de um serviço para uma invocação de função, cobrá-la por milissegundo, escalá-la a zero entre requisições. Lembro da empolgação, e lembro do que aconteceu em seguida: quase nada. O serverless se acomodou nas bordas dos sistemas — redimensionamento de imagens, cola entre serviços gerenciados, jobs de cron — e o núcleo de todo backend sério permaneceu em servidores de longa duração. A razão nunca foi o compute. Foi que uma função que esquece tudo entre invocações empurra todo o seu estado para um banco de dados a cada chamada, e no momento em que seu domínio precisa de um contador, uma sessão, um workflow, um lock ou um WebSocket, você está construindo máquinas de estado distribuídas na mão sobre o DynamoDB e pagando latência por cada byte de memória que você costumava obter de graça. A unidade encolheu; o estado quebrou; e desta vez a primitiva que conserta isso não chegou no prazo. A onda emperrou por quase uma década.

O padrão: a unidade encolhe, o estado quebra, uma primitiva emerge

Colocadas lado a lado, as três ondas rodam o mesmo programa. A unidade de deploy encolhe — servidor, depois serviço, depois invocação. O encolhimento quebra qualquer mecanismo de estado do qual a geração anterior dependia — o heap compartilhado, depois a transação compartilhada, depois a própria memória. A lacuna é preenchida por novas primitivas de estado — a transação do RDBMS; depois sagas, outboxes e protocolos de idempotência; depois, para a terceira onda, a camada de estado durável que passou de 2024 a 2026 saindo de pesquisa e beta para disponibilidade geral. Uma vez que a primitiva aterrissa, a unidade menor se torna segura para cargas de trabalho centrais, e o padrão default muda.

O diagrama abaixo é a tese inteira em uma linha: o ponto de fratura de cada onda, e a primitiva que o selou.

Quero ser preciso sobre o que "a primitiva chegou" significa, porque essa afirmação sustenta o post. Então aqui vai a revisão do panorama — o que de fato foi lançado, com datas, enquanto eu estava de cabeça baixa construindo serviços Spring Boot.

O que foi lançado enquanto eu construía serviços Spring Boot

A evidência se organiza em três prateleiras: o compute ficou efêmero e barato de interromper, o estado ficou durável e co-localizado, e uma nova geração de frameworks começou a pressupor ambos.

A prateleira do compute: de curta duração por padrão

O Cloudflare Workers é a expressão mais limpa da nova unidade. Um Worker não é um contêiner que dá boot — é um isolate V8 criado dentro de um runtime já em execução, que é como a Cloudflare elimina o cold start do modelo de máquina virtual. O preço é a parte interessante: no plano pago (mínimo de US$ 5/mês, 10 milhões de requisições incluídas), você é cobrado apenas por tempo de CPU — US$ 0,02 por milhão adicional de CPU-milissegundos — e o tempo de relógio (wall-clock) é gratuito. Um Worker aguardando a resposta de um banco de dados não custa nada enquanto espera. Egress não custa nada. O medidor de cobrança literalmente não consegue enxergar a ociosidade. Os tetos são reais (5 minutos de CPU por invocação, nenhum binário Linux arbitrário no isolate), e a extensão Workers Containers de 2025 — cobrada a cada 10 milissegundos de atividade — mostra a Cloudflare puxando até cargas de contêiner para o mesmo enquadramento de cobrança por uso.

A Vercel passou 2025 reconstruindo seu runtime de funções em torno da mesma ideia. O Fluid compute (anunciado em fevereiro de 2025, padrão para novos projetos desde abril) permite que uma instância de função sirva invocações concorrentes em vez do modelo estilo Lambda de um-sandbox-por-requisição, e o preço Active CPU que se seguiu em junho de 2025 cobra três medidores: CPU ativa a US$ 0,128/hora, memória provisionada a US$ 0,0106/GB-hora, e US$ 0,60 por milhão de invocações. A documentação deles enuncia o modelo com clareza: a cobrança de CPU pausa enquanto uma requisição espera por I/O, e entre requisições você não paga absolutamente nada.

O AWS Lambda, origem da onda, silenciosamente consertou seu pior número para pessoas como eu. O preço não mudou de forma — US$ 0,0000166667 por GB-segundo no x86 (arm64 é 20% menos), US$ 0,20 por milhão de requisições, cobrado por milissegundo, com teto rígido de 15 minutos — mas o SnapStart retoma uma função a partir de um snapshot Firecracker em cache do runtime totalmente inicializado, em vez de reexecutar a inicialização. Para Java — o runtime cujos cold starts pesados de framework a própria AWS descreve como levando "vários segundos" — o SnapStart é gratuito e reduz a retomada para menos de um segundo. O imposto de cold start da JVM, a maior razão isolada pela qual minha stack profissional e o serverless nunca se misturaram, foi reduzido por engenharia a um erro de arredondamento.

O Fly.io ataca pela direção oposta: em vez de encolher o runtime, torna VMs completas baratas de parar. Uma Fly Machine é um microVM real com um ciclo de vida REST; criar uma leva alguns dígitos baixos de segundos, mas iniciar uma que estava parada leva bem menos de um segundo, o que torna o stop-on-idle um padrão rotineiro em vez de uma indisponibilidade. A cobrança é por segundo enquanto roda — uma shared-cpu-1x com 256 MB custa cerca de US$ 1,94/mês se nunca dormir — e uma Machine parada custa apenas o armazenamento do seu sistema de arquivos raiz, a US$ 0,15 por GB a cada 30 dias. Um servidor que dorme por US$ 0,15 ao mês e acorda em 300 milissegundos não é realmente um servidor no sentido em que aprendi a palavra.

Até o mundo Kubernetes — o lar institucional do processo de longa duração — está convergindo. O Knative, a camada scale-to-zero orientada a requisições em cima do k8s, graduou-se como projeto da CNCF em outubro de 2025. A diferença, e ela importa mais adiante neste post, é que o Knative escala pods stateless a zero; ele nada diz sobre para onde vai o estado deles quando desaparecem.

A prateleira do estado: durable objects, atores e workflows reproduzíveis

A prateleira do compute sozinha apenas repetiria o impasse de 2016. A prateleira do estado é o que mudou.

A ancestralidade intelectual é o Microsoft Orleans, cujo artigo "virtual actor" de 2014 — construído para rodar o backend de Halo — propôs atores que existem perpetuamente e ativam sob demanda: você endereça uma entidade pela identidade, o runtime a materializa onde quer que haja capacidade, e seu estado a acompanha. O Orleans permaneceu uma ideia .NET por anos. O que a onda atual fez foi fundir atores virtuais com runtimes de borda e cobrança por uso.

O Cloudflare Durable Objects é o carro-chefe dessa fusão. Um Durable Object é uma instância globalmente única e nomeada de uma classe — single-threaded, então processa uma mensagem por vez — com armazenamento transacional co-localizado com o compute. Beta em 2020, GA no fim de 2021, e a peça que me fez prestar atenção: o armazenamento baseado em SQLite ficou GA em abril de 2025, dando a cada objeto seu próprio banco de dados relacional de até 10 GB, acessado na velocidade da memória porque os dados vivem junto do objeto. A economia segue a prateleira do compute: a duração é cobrada apenas enquanto o objeto está ativo em memória, e a WebSocket Hibernation API pode despejar um objeto ocioso mantendo suas conexões abertas — o próprio exemplo trabalhado da Cloudflare precifica 10.000 conexões WebSocket hibernando em cerca de US$ 10/mês contra cerca de US$ 417 sem hibernação. Um objeto com o qual não estão conversando custa centavos de armazenamento. Esta é a primitiva que faltava ao serverless em 2016: um lugar para o estado que escala a zero junto com o compute em vez de brigar com ele.

O modelo não é mais proprietário de um único fornecedor. O Rivet Actors — lançado publicamente em dezembro de 2024, Apache 2.0, construído em Rust — é uma implementação open-source da mesma forma: atores leves cujo estado em memória persiste automaticamente (SQLite ou traga seu próprio banco de dados), que dormem quando ociosos e acordam sob demanda, auto-hospedáveis como um único binário ou rodando na nuvem deles, e implantáveis na Vercel desde outubro de 2025. Os benchmarks deles afirmam cold starts de ator em torno de 20 milissegundos. Eu mesmo não verifiquei esse número, e para este post ele importa menos do que sua ordem de grandeza: acordar o estado agora é medido em milissegundos, não em segundos de JVM.

A metade de workflow da prateleira do estado é a execução durável, e ali eu já paguei meu pedágio. Minhas anotações sobre o Restate cobrem o mecanismo central e seu custo: o runtime registra em journal cada passo de um workflow, reproduz o journal após um crash, e em troca exige determinismo do seu código — a linha que quebrou o replay na minha reconciliação de pagamento de seis passos foi um timestamp inocente. O Temporal industrializou esse modelo (seus fundadores construíram o Cadence no Uber e o forkaram em 2019) e o mercado acabou de precificar o momentum da categoria: uma Série D de US$ 300 milhões a uma avaliação de US$ 5 bilhões em fevereiro de 2026, com a OpenAI citada entre os clientes. O Restate, dos criadores do Apache Flink, comprime a mesma garantia em um único binário Rust que empurra invocações para handlers stateless simples — incluindo o Lambda — e publica latências p99 abaixo de 170 milissegundos para um workflow de dez passos. Comparei os trade-offs operacionais da categoria em DBOS vs Temporal — a versão curta é que a execução durável deixou de ser infraestrutura exótica e se tornou algo que um único engenheiro consegue operar.

Entre durable objects para estado de entidade e execução durável para estado de workflow, as duas formas de "estado que sobrevive à morte do seu compute" ambas chegaram a grau de produção enquanto o próprio compute aprendia a morrer barato. Essa coincidência é a zona de transição.

A prateleira das premissas: frameworks que dão tudo isso como certo

O indício de que um substrato chegou é quando novos frameworks param de explicá-lo. A Vercel introduziu o Eve em junho de 2026 — um framework de agentes open-source onde um agente é um diretório, implantado como qualquer outro projeto — e sua arquitetura simplesmente pressupõe a nova stack: execução durável para loops de agente de longa duração, compute efêmero em sandbox para chamadas de ferramenta, aprovações human-in-the-loop que estacionam um workflow por horas sem nenhum processo esperando em lugar algum. O Eve não é em si um produto de compute; ele é evidência do que seus autores consideram ambiente dado. E a carga de trabalho que ele atende é o caso mais puro para a nova economia: a Vercel relata que agentes agora disparam cerca de 29% dos deploys em sua plataforma, contra menos de 3% um ano antes — tráfego que é intermitente, não supervisionado e cheio de ociosidade, exatamente a forma que torna pagar-para-esperar indefensável.

A mesma premissa está alcançando para além do backend por completo. Escrevi recentemente sobre arquitetura local-first, onde o cliente detém a cópia autoritativa e o servidor é rebaixado a um relay de sincronização — e sobre hybrid logical clocks, a primitiva de ordenação à qual você recorre quando nenhum relógio de servidor único define o "depois". Lidos à luz deste post, esses são a mesma transição vista pelo lado do cliente: o estado migrando para fora da camada sempre-ligada, com o data center mantendo exatamente os papéis — relay, backup, escritas-de-recusa, workflows — que a prateleira do estado durável implementa. O quadro se compõe: funções efêmeras na borda da requisição, durable objects e workflows onde a autoridade precisa residir, clientes sendo donos daquilo que conseguem mesclar. Nada nesse quadro espera.

A conta é o indício revelador

Artigos de arquitetura podem discutir para sempre; páginas de preço são falsificáveis. Então aqui está minha pergunta — pagar antecipadamente por prontidão, ou pagar por unidade de trabalho — com números de 2026 dos dois lados.

A linha de base da espera: uma task AWS Fargate com 1 vCPU e 2 GB — um lar modesto para um serviço Spring Boot — custa cerca de US$ 36/mês em us-east-1, com tráfego ou sem. Uma instância EC2 t4g.medium fica em cerca de US$ 24,50. Agora multiplique do jeito que os parques reais multiplicam: por serviço, por ambiente. Vinte microsserviços em dev, staging e produção são sessenta tasks sempre-ligadas — digamos US$ 2.100/mês a preços de Fargate — das quais a esmagadora maioria dos vCPU-segundos é gasta fazendo health-check. Esse é o piso de ociosidade, e cada exercício de capacity planning que já rodei foi uma tentativa de aparar esse piso sem tomar um alerta no pager.

A coluna do pagamento por uso: a mesma requisição tratada por um Lambda de 1 GB custa US$ 0,0000167 por GB-segundo mais US$ 0,20 por milhão de requisições, medido por milissegundo. A aritmética que importa: um Lambda de 1 GB rodando a todo vapor, 24/7, custa cerca de US$ 44/mês — mais do que a task Fargate que ele substituiria. Rode-o 10% do tempo e ele custa US$ 4,40. Rode-o 1% do tempo — o ciclo de trabalho de uma ferramenta interna, um receptor de webhook, um gerador de relatórios — e ele custa 44 centavos. O Workers afia ainda mais essa mesma borda ao cobrar apenas CPU-milissegundos, de modo que até a espera de relógio dentro de uma requisição é gratuita; o modelo Active CPU da Vercel faz o mesmo para o ecossistema Node. E a camada de estado agora segue a mesma curva em vez de brigar com ela: um Durable Object hiberna para centavos de armazenamento, uma Fly Machine parada custa US$ 0,15/GB de rootfs, um workflow Restate estacionado é linhas em um log, não uma thread em um pool.

O ponto de cruzamento é a parte honesta, e corta nos dois sentidos.

​

Abaixo do ponto de cruzamento — cargas de trabalho cheias de ociosidade, com picos, não supervisionadas — o preço por uso não é uma otimização, é uma categoria diferente de conta. Acima dele — carga sustentada, plana, previsível — o modelo antigo vence em dólares puros: uma função Vercel fixada a 100% de CPU ativa roda cerca de US$ 109/mês contra aquela task Fargate de US$ 36, e a aritmética do Lambda acima já mostrou a mesma inversão. Pagar por uso é uma aposta na ociosidade. O que torna a aposta recém-interessante é que o mix de cargas de trabalho da indústria está derivando para o extremo cheio de ociosidade — agentes, webhooks, serviços por tenant, APIs de cauda longa — no mesmo momento em que as primitivas chegaram. A economia e a mecânica estão empurrando na mesma direção. É assim que uma zona de transição se parece por dentro.

O argumento mais forte contra a minha própria tese

Desconfio de qualquer argumento meu que não tenha um bom oponente, e este tem quatro.

O incumbente não está parado. A JVM de longa duração de 2026 não é a que empurrou a indústria para os microsserviços. As virtual threads depois da JEP 491 removeram o problema de pinning e moveram o gargalo; o Java 26 traz cache de objetos AOT que ataca startup e warmup diretamente. Uma JVM aquecida em utilização sustentada continua sendo uma das formas mais baratas e mais entediantes de servir carga plana já construídas — e entediante é uma feature pela qual eu já cobrei. Se seu tráfego é plano, o gráfico do ponto de cruzamento já lhe disse a resposta, e ela não é o Lambda.

O gradiente de lock-in é íngreme. Código de Durable Objects roda na Cloudflare e em nenhum outro lugar. O Rivet é Apache 2.0 e auto-hospedável — essa é precisamente sua proposta. O Restate é BSL 1.1: livre para auto-hospedar em produção, com código-fonte disponível, cada release convertendo-se para Apache 2.0 após quatro anos, mas não OSI-open hoje. O Temporal é MIT, e auto-hospedá-lo significa operar um cluster de múltiplos serviços mais Cassandra ou Postgres mais, geralmente, Elasticsearch. Cada opção precifica a saída de forma diferente, e depois do post sobre local-first eu peso o custo de saída como uma propriedade arquitetural de primeira classe, não uma nota de rodapé de compras.

As primitivas têm arestas afiadas nas quais eu já me cortei. Um único durable object é single-threaded — uma entidade quente vira um teto de throughput, exatamente o trade que medi no bake-off ator-por-entidade, onde o modelo de ator não removeu o problema difícil, apenas o moveu para a correção de roteamento e rebalanceamento. A execução durável impõe uma disciplina de determinismo que minhas anotações sobre o Restate documentam linha por linha, e versionar um workflow que tem milhares de execuções em andamento é uma habilidade operacional de que o mundo sempre-ligado nunca precisou. APIs no formato de hibernação são obrigatórias, não opcionais: um Durable Object segurando um WebSocket não hibernado paga duração de relógio o tempo todo, e "serverless" silenciosamente vira um servidor com ergonomia pior.

E os tetos ainda existem: 15 minutos no Lambda, 5 CPU-minutos no Workers, taxas de egress que podem dominar o compute para APIs com uso intensivo de dados em toda parte, exceto na Cloudflare. Nada disso afunda a tese. Tudo isso delimita onde a tese se aplica — que é exatamente para o que serve a próxima seção.

O experimento: fazer um teste A/B da minha própria história

Ler não é evidência. Então aqui está o compromisso que este post existe para firmar.

Venho construindo sistemas Spring Boot há anos, e há um problema no meu passado — um que já resolvi uma vez naquele mundo, cujos requisitos e modos de falha conheço intimamente — que vou construir de novo sobre o novo substrato: compute efêmero para o caminho da requisição, durable objects ou atores para o estado de entidade, execução durável para os workflows. Chame a arquitetura original de A e a reconstrução de B. Estou deliberadamente ainda não nomeando o problema; o próximo post desta série apresenta o problema, suas invariantes, e o design original tal como ele de fato era, antes que B ganhe uma linha de código.

O que vou manter constante: funcionalidade idêntica, requisitos de correção idênticos, e uma suíte de testes completa dos dois lados — incluindo os testes de concorrência e retentativa, porque idempotência sob retentativas é onde as arquiteturas vão para serem pegas mentindo.

O que vou medir, em público, com o método exibido:

• Custo sob três formatos de tráfego — cheio de ociosidade, com picos e sustentado — porque o gráfico do ponto de cruzamento acima é uma hipótese até ter os números da minha carga de trabalho nele.
• Latência, p50 e p99, incluindo os caminhos frios — retomadas do SnapStart, despertares de ator e replays de workflow incluídos, não excluídos como ruído de aquecimento.
• Superfície operacional — o que pode me acordar com um alerta às 3 da manhã em cada arquitetura, e quanto de cada sistema eu preciso entender para consertá-lo.
• Correção de estado sob injeção de falhas — matar o processo no meio do workflow, colocar as escritas concorrentes em corrida, e comparar o que cada modelo faz por construção versus por minha própria disciplina.
• Custo de saída — o que seria necessário para mover cada build para um provedor diferente, medido em linhas alteradas e premissas alteradas.

Se B perder, a série dirá isso com todas as letras — um resultado negativo contra a minha própria tese ainda é um resultado sobre o qual posso construir. Mas o padrão já rodou três vezes na minha carreira, e a cada vez os engenheiros que reconheceram a zona cedo passaram os cinco anos seguintes à frente dos que esperaram por permissão.

Os pontos que levo comigo para a parte dois:

• A unidade de deploy de backend encolhe em ondas, e cada onda quebra o estado antes que uma nova primitiva torne a unidade menor segura. A primitiva para a onda serverless — durable objects, atores, execução durável — foi lançada entre 2024 e 2026.
• O modelo de cobrança é o sinal arquitetural: quando o medidor para de cobrar pela ociosidade (cobrança por CPU-ms, hibernação, máquinas paradas a custo de armazenamento), a plataforma está lhe dizendo qual unidade ela quer que você entregue.
• Pagar por uso é uma aposta na ociosidade. Aceite-a para cargas com picos, não supervisionadas, de cauda longa, por tenant; recuse-a para carga plana sustentada, onde uma JVM aquecida continua sendo a vencedora honesta.
• Custo de saída é uma propriedade de primeira classe agora: a mesma capacidade abrange uma borda proprietária (Durable Objects), auto-hospedagem Apache 2.0 (Rivet), BSL (Restate) e MIT-com-peso-operacional (Temporal).
• Confie no A/B, não no manifesto — o meu incluído. É para isso que serve o resto desta série.

Leitura adicional

• Cloudflare Durable Objects — SQLite storage GA e preços do Durable Objects
• Vercel — Introducing Eve e preço Active CPU para Fluid compute
• Rivet — atores open-source
• AWS Lambda SnapStart e preços do Lambda
• Fly Machines e preços do Fly.io
• Restate vs Temporal e o artigo sobre o virtual-actor do Orleans
• Knative se gradua na CNCF