System Design/04 - Cloud Design Patterns/Design & Implementation2 min
Backends for Frontend
- Que problema isso resolve?
- Quando usar / quando NÃO usar?
- Qual o principal trade-off?
- Como isso falha em produção?
Conceito
Um backend por tipo de cliente, em vez de uma API genérica que tenta servir a todos.
app móvel → BFF-mobile ┐
web → BFF-web ├→ serviços de domínio
parceiros → BFF-público ┘
Cada BFF conhece as necessidades do seu cliente: quais campos, qual formato, qual agregação, qual cadência de release.
Trade-offs
O problema que ele resolve é real. Uma API única acaba servindo mal a todos: o app móvel quer poucos campos e poucas chamadas; a web quer dados ricos; o parceiro quer estabilidade de contrato por anos. Atender os três com um endpoint produz over-fetching para um, under-fetching para outro, e paralisia de evolução por causa do terceiro.
Com BFFs, cada um evolui no próprio ritmo — e o time do app móvel pode mudar seu BFF sem coordenar com ninguém.
Os custos:
Duplicação. Lógica de composição repetida entre BFFs. É o custo aceito, e ele só é aceitável se os BFFs permanecerem finos — agregação e formatação, nunca regra de negócio.
Mais serviços para operar. Três BFFs são três deploys, três monitoramentos, três pipelines.
Risco de virar monolito distribuído. Se lógica de domínio migra para os BFFs, ela passa a existir em três lugares divergentes — o pior resultado possível.
A alternativa direta é GraphQL: um endpoint em que cada cliente pede o que precisa, sem um backend por cliente. Ele resolve o mesmo problema por outro caminho, com seus próprios custos (cache, N+1, custo de query).
O critério de adoção costuma ser organizacional: BFF faz sentido quando existe um time por cliente, e cada um quer autonomia de release.
Exemplo prático
A mesma tela de perfil, servida a dois clientes:
BFF-mobile: { nome, avatar_pequeno, notificacoes } ~200 bytes
BFF-web: { nome, avatar_grande, bio, ultimos_pedidos,
enderecos, preferencias } ~4 KB
Ambos compõem a partir dos mesmos serviços de domínio. O móvel otimiza para bytes e latência em rede ruim; a web otimiza para riqueza.
Se o app móvel precisar de um campo novo amanhã, o time dele altera seu BFF e publica. Com API única, essa mudança entraria numa fila de prioridades compartilhada com todos os outros clientes.
Relacionado
Parte de Design & Implementation · roadmap.sh/system-design