Forem: Rodrigo Albornoz

Frugal Cascade: um padrão de resiliência para arquiteturas com orçamento zero

Rodrigo Albornoz — Mon, 11 May 2026 03:00:00 +0000

Projetos pessoais, side projects e MVPs raramente nascem com orçamento. A realidade da maioria dos desenvolvedores independentes é clara: você tem uma ideia, tem habilidade técnica, mas não tem verba para pagar por cinco serviços ao mesmo tempo. Felizmente, hoje em dia temos acesso a uma quantidade generosa de planos gratuitos espalhados por dezenas de plataformas. E isso pode ser mais do que suficiente para construir algo resiliente.

Este artigo propõe e formaliza um padrão de arquitetura que combina encadeamento de fallbacks com aproveitamento estratégico de free tiers: o Frugal Cascade.

O problema

Quando você depende de um único provedor externo, assume um risco silencioso. Se o serviço cair, sua funcionalidade cai junto. Se o limite gratuito for atingido, sua aplicação para. Em produção com orçamento, a solução é pagar por redundância. Em projetos com orçamento zero, a solução exige uma abordagem diferente.

O Frugal Cascade responde a essa restrição com uma premissa simples: distribuir responsabilidade por múltiplos provedores gratuitos, em ordem de preferência, com degradação controlada até um estado mínimo aceitável.

Definição formal

Frugal Cascade é um padrão de resiliência para arquiteturas com restrição de custo que estrutura o acesso a serviços externos em uma cadeia ordenada de provedores alternativos, onde cada nó representa um fallback acionado apenas na falha do anterior. A cadeia termina em um last resort, que é uma ação mínima garantida que preserva a integridade do sistema mesmo na ausência de todos os provedores disponíveis.

O padrão é composto por três elementos:

Cadeia de provedores: lista ordenada de provedores que oferecem a mesma capacidade funcional, priorizados por confiabilidade, latência ou preferência.
Condição de fallback: critério que dispara a progressão para o próximo nó (timeout, erro HTTP, limite de quota atingido).
Last resort: ação final executada quando todos os provedores falham. Essa ação pode ser um estado degradado, um dado em cache, uma flag para revisão humana ou simplesmente um erro controlado.

Relação com padrões existentes

O Frugal Cascade não é um padrão completamente novo. Ele é uma especialização pragmática de conceitos já estabelecidos, adaptados para o contexto de restrição orçamentária:

Padrão base	Contribuição ao Frugal Cascade
Fallback Pattern	Estrutura central de encadeamento
Graceful Degradation	Filosofia de preservação do estado mínimo
Chain of Responsibility (GoF)	Modelo de implementação em código
Circuit Breaker	Complemento recomendado para evitar tentativas repetidas em provedores indisponíveis

A diferença que justifica um nome próprio está na motivação e no contexto de aplicação: enquanto os padrões acima são geralmente aplicados para garantir alta disponibilidade em sistemas críticos com múltiplos provedores pagos, o Frugal Cascade tem como premissa central o custo zero, e a redundância é obtida justamente pela diversificação entre planos gratuitos de plataformas distintas.

Estrutura do padrão

Requisição
    │
    ▼
┌─────────────┐
│  Provedor 1 │ ──── sucesso ──▶ Resposta
└─────────────┘
       │ falha
       ▼
┌─────────────┐
│  Provedor 2 │ ──── sucesso ──▶ Resposta
└─────────────┘
       │ falha
       ▼
┌─────────────┐
│  Provedor N │ ──── sucesso ──▶ Resposta
└─────────────┘
       │ falha
       ▼
┌──────────────┐
│  Last Resort │ ──────────────▶ Estado mínimo garantido
└──────────────┘

A progressão ocorre de forma sequencial e sob demanda, o próximo nó só é acionado quando o anterior falha. Isso é diferente de um load balancer, que distribui carga entre provedores ativamente. No Frugal Cascade, a redundância é passiva e ordenada.

Exemplos práticos

1. Moderação de conteúdo em upload de imagens

Objetivo: garantir que nenhuma imagem passe sem análise, sem pagar por um único serviço.

Cadeia:

SightEngine (análise primária)
PicPurify (fallback secundário)
Google Vision API (fallback terciário)
Last resort: imagem recebe flag pending_manual_review e entra em fila de auditoria humana

async function moderateImage(imageUrl: string): Promise<ModerationResult> {
  const providers = [
    () => analyzWithSightEngine(imageUrl),
    () => analyzeWithPicPurify(imageUrl),
    () => analyzeWithGoogleVision(imageUrl),
  ];

  for (const provider of providers) {
    try {
      return await provider();
    } catch (error) {
      console.warn("Provider failed, trying next...", error);
    }
  }

  // Last resort: degradação controlada
  await flagForManualReview(imageUrl);
  return { status: "pending_review", automated: false };
}

O last resort aqui é particularmente importante: a falha total dos provedores automatizados não resulta em conteúdo não moderado, resulta em revisão humana. O sistema preserva sua garantia de segurança mesmo sem nenhum serviço disponível.

2. Armazenamento de arquivos com distribuição aleatória entre free tiers

Objetivo: maximizar o uso combinado dos limites gratuitos do Supabase Storage e Firebase Storage.

Variação do padrão: neste caso, o primeiro nó não é escolhido por prioridade, mas por seleção aleatória. Isso distribui os uploads uniformemente ao longo do tempo, evitando que um único provedor atinja seu limite antes do outro.

const storageProviders = [
  uploadToSupabase,
  uploadToFirebase,
];

async function uploadFile(file: File): Promise<string> {
  // Embaralha para distribuição uniforme de carga
  const [primary, fallback] = shuffle(storageProviders);

  try {
    return await primary(file);
  } catch {
    try {
      return await fallback(file);
    } catch {
      throw new Error("All storage providers unavailable");
    }
  }
}

Nota: este exemplo não tem last resort, um erro é o estado mínimo aceitável quando nenhum provedor de armazenamento está disponível. Nem toda implementação do Frugal Cascade precisa de um last resort funcional; às vezes, falhar de forma explícita e controlada é a decisão correta.

3. Dados de clima em tempo real

Objetivo: garantir disponibilidade de dados meteorológicos sem dependência de um único provedor.

Cadeia:

WeatherAPI
OpenWeatherMap
Open-Meteo (open source, sem chave de API, sem limite)

async function getCurrentWeather(lat: number, lon: number): Promise<WeatherData> {
  const providers = [
    () => fetchFromWeatherAPI(lat, lon),
    () => fetchFromOpenWeatherMap(lat, lon),
    () => fetchFromOpenMeteo(lat, lon),  // fallback confiável e irrestrito
  ];

  for (const provider of providers) {
    try {
      return await provider();
    } catch {
      continue;
    }
  }

  throw new Error("All weather providers unavailable");
}

Observação de design: o Open-Meteo, por ser open source e não ter limite de requisições, funciona como um âncora de confiabilidade no final da cadeia, um nó quase garantido. Quando disponível, esse tipo de provedor deve sempre ocupar a última posição antes do last resort.

4. Inferência com LLMs gratuitos via múltiplas plataformas

Objetivo: garantir respostas de modelos de linguagem sem custo, com fallback entre OpenRouter e Groq.

Cadeia:

Grupo 1 - OpenRouter (modelos free):

meta-llama/llama-3.3-70b-instruct:free
openai/gpt-oss-120b:free
minimax/minimax-m2.5:free

Grupo 2 - Groq (fallback de plataforma, modelos também free):

llama-3.3-70b-versatile
deepseek-r1-distill-llama-70b
openai/gpt-oss-120b

const LLM_CHAIN = [
  { platform: "openrouter", model: "meta-llama/llama-3.3-70b-instruct:free" },
  { platform: "openrouter", model: "openai/gpt-oss-120b:free" },
  { platform: "openrouter", model: "minimax/minimax-m2.5:free" },
  { platform: "groq",       model: "llama-3.3-70b-versatile" },
  { platform: "groq",       model: "deepseek-r1-distill-llama-70b" },
  { platform: "groq",       model: "openai/gpt-oss-120b" },
];

async function chat(prompt: string): Promise<string> {
  for (const { platform, model } of LLM_CHAIN) {
    try {
      return await callLLM(platform, model, prompt);
    } catch {
      continue;
    }
  }

  throw new Error("All LLM providers exhausted");
}

Este exemplo introduz uma variante importante: a cadeia é organizada em grupos por plataforma. Isso é relevante porque erros dentro do mesmo grupo podem ter a mesma causa (rate limit da plataforma, autenticação inválida), e a progressão para o próximo grupo representa uma mudança de plataforma, não apenas de modelo.

Quando aplicar o Frugal Cascade

O padrão é adequado quando:

O projeto opera com orçamento zero ou muito restrito
A funcionalidade tem equivalentes funcionais disponíveis gratuitamente em múltiplos provedores
A falha total da funcionalidade é inaceitável, mas uma resposta degradada é tolerável
O volume de uso é compatível com os limites dos planos gratuitos escolhidos

O padrão não é adequado quando:

O sistema é crítico e exige SLA formal: neste caso, provedores pagos com garantias contratuais são necessários
Há apenas um provedor com a capacidade necessária: o padrão depende de equivalência funcional entre provedores
Os dados trafegados são sensíveis e cada provedor introduz um novo terceiro com acesso a eles: o custo de privacidade pode superar o benefício de custo

Considerações de implementação

Circuit Breaker como complemento

Em produção, mesmo em projetos pessoais, vale considerar o uso de um circuit breaker por provedor. Em vez de tentar um provedor que falhou repetidamente, o circuito "abre" temporariamente e o sistema pula diretamente para o próximo nó. Isso evita latência desnecessária em cascata.

const breakers = new Map<string, CircuitBreaker>();

function getBreaker(providerId: string): CircuitBreaker {
  if (!breakers.has(providerId)) {
    breakers.set(providerId, new CircuitBreaker({ timeout: 60_000 }));
  }
  return breakers.get(providerId)!;
}

Logging e observabilidade

Registre qual nó da cadeia foi utilizado em cada requisição. Sem isso, é impossível saber se um provedor está falhando sistematicamente ou se a distribuição entre provedores está equilibrada.

Normalização de resposta

Provedores diferentes retornam formatos diferentes. Uma camada de adaptadores por provedor, que normaliza a saída para um contrato interno único, é fundamental para que a lógica de negócio não precise saber qual provedor respondeu.

Conclusão

O Frugal Cascade não é apenas uma técnica de economia, é uma disciplina de design que força clareza sobre dependências externas, comportamento em falha e graus de degradação aceitáveis. Sistemas construídos com esse padrão são, por natureza, mais resilientes do que sistemas que assumem disponibilidade irrestrita de um único provedor.

A restrição orçamentária, neste caso, produz um efeito colateral positivo: ela obriga o desenvolvedor a pensar em redundância desde o início, algo que projetos com orçamento generoso frequentemente adiam até que seja tarde demais.

Construído com base em experiência prática com projetos pessoais de orçamento zero. Feedbacks e variações do padrão são bem-vindos nos comentários.

A Treta do Module Federation e Next.js: Uma História de Falta de Colaboração

Rodrigo Albornoz — Thu, 06 Nov 2025 03:23:31 +0000

Durante meus estudos sobre micro-frontends, especialmente o uso de Module Federation com Next.js, busquei maneiras de integrar essa tecnologia utilizando o novo bundler do framework, o Turbopack.

Encontrei diversas discussões no GitHub e em fóruns da comunidade que revelaram um debate interessante no ecossistema React/Next.js.

Neste texto, compartilho o que descobri: o que ocorreu, os principais pontos de atrito e a importância disso para quem trabalha com React e micro-frontends.

Module Federation — o que é e por que importa

O Module Federation, criado por Zack Jackson (@scriptedalchemy), é um recurso do Webpack 5 que permite dividir aplicações em módulos independentes, carregados em runtime. Isso possibilita uma arquitetura de micro-frontends flexível e escalável, permitindo que diferentes equipes atualizem partes da aplicação isoladamente, sem a necessidade de recompilar tudo, melhorando a agilidade e a performance em projetos grandes.

Next.js e a filosofia da Vercel

O Next.js, mantido pela Vercel, é um dos frameworks React mais populares, conhecido pela simplicidade e performance, além de oferecer recursos como SSG e SSR. No entanto, sua filosofia se baseia no build-time, processando e empacotando grande parte do código antes do deploy, o que, embora melhore a performance, torna mais complexa a adoção de soluções que dependem de carregamento dinâmico em runtime, como o Module Federation.

Build-Time vs Runtime: o conflito filosófico

O conflito entre Next.js e Module Federation é mais conceitual do que técnico. Enquanto a Vercel acredita que todo código deve estar disponível no build, o Module Federation defende o carregamento dinâmico de módulos em runtime, criando uma barreira natural para a integração entre as duas abordagens.

O conflito com a Vercel

Zack tentou colaborar com o time do Next.js por anos para desenvolver uma integração oficial com o Module Federation, mas enfrentou resistência.

A resposta da Vercel foi: “não está nos nossos planos”.

Em julho de 2022, Zack declarou:

“Não haverá suporte oficial para o Module Federation pela Vercel. Eles acreditam que tudo deve estar disponível no build. Ele nunca será suportado pelo Next.js.”

Diante disso, ele criou uma solução comercial (@module-federation/nextjs-mf) para financiar o desenvolvimento e, meses depois, abriu parcialmente o código como open source para pressionar a Vercel.

Em um podcast de novembro de 2024, Zack anunciou o fim do suporte ao Next.js:

“O plugin teve um ciclo de desenvolvimento muito doloroso… requer muitos recursos e não é desejado. O Turbopack está a caminho, e não sabemos se ele suportará o Module Federation; sua morte já estava escrita na parede.”

“Não apoiaremos um framework que não o quer. Se a Vercel decidir apoiar o Module Federation como prioridade, eu dobraria os recursos para ajudá-los, mas não posso fazer isso sozinho sem apoio interno.”

Curiosamente, após esse anúncio, a Vercel começou a demonstrar interesse em reconsiderar o suporte, mas até o momento não há nada oficial.

Caminhos alternativos e o futuro

O Next.js oferece uma solução chamada Multi-Zones, que permite dividir a aplicação em áreas independentes, porém isso ocorre em build-time e exige recarregamento completo entre zonas, reduzindo a fluidez da experiência e limitando o conceito de micro-frontends. Enquanto isso, o Module Federation continua sendo o padrão de mercado para micro-frontends dinâmicos, amplamente adotado por grandes empresas. Outras ferramentas, como Single-SPA e Rspack, também estão ganhando destaque nas discussões sobre o futuro dessa arquitetura.

Open Source ou Open Corporate?

Esse debate levanta a questão: até que ponto vale a pena depender de tecnologias controladas por empresas privadas? A Vercel tem seus méritos, mas o caso do Module Federation mostra como interesses comerciais podem limitar a inovação aberta. Em contraste, frameworks como Nuxt.js, mantidos pela comunidade, destacam o valor de ecossistemas verdadeiramente open source.

Recentemente, a Meta transferiu o React para a Linux Foundation, criando a React Foundation, um passo simbólico para dar mais autonomia à comunidade. No entanto, a maioria dos desenvolvedores principais do React ainda pertence à Meta e à Vercel, mantendo a influência corporativa.

Conclusão

O embate entre Module Federation e Next.js reflete o atrito entre inovação aberta e estratégia empresarial. Zack e a equipe da Vercel possuem visões distintas sobre o futuro do frontend, e a comunidade está no meio desse impasse.

Independentemente de qual lado você possa achar que tem mais razão, entender essas tensões é crucial para fazer escolhas de arquitetura mais conscientes, escaláveis e alinhadas com o futuro do ecossistema React.