Backends for Frontends Explained | BFF Pattern vs a Shared API

How do you design an API when a customer phone and a staff dashboard need different data from the same services? That's the problem Backends for Frontends helps address. In this video, we explore Backends for Frontends: an architecture pattern that gives each distinct frontend experience a backend contract shaped around its tasks, payloads, and ownership. The lesson uses a practical story, evolving diagrams, and a worked prediction exercise. You'll learn: What Backends for Frontends means in software design What problem Backends for Frontends helps solve Why one large response can serve both screens badly How a phone BFF returns a compact menu response How a staff BFF composes operational data Why core order rules stay with their authoritative service How authorization, identity-aware caching, and failures affect each BFF How a BFF can coexist with a shared API gateway When to use Backends for Frontends in your own code The benefits, limitations, and trade-offs shown in the worked example The key idea is simple: Shape a backend around an experience and keep shared business decisions with their owner. Compare a cafe's customer menu with its staff preparation dashboard. BFF is useful when experiences diverge enough to justify separate contracts and ownership, without creating a backend for every page. CHAPTERS 00:00 The same response serves neither screen well 01:15 Identify the staff task separately 02:41 Trace the staff request 04:13 Tailor failure behavior to the experience 05:39 Ownership is part of the pattern 07:07 Check contracts against useful scenarios 08:17 Apply it where experiences truly diverge Sources and attribution https://samnewman.io/patterns/archite... https://microservices.io/patterns/api... https://learn.microsoft.com/en-us/azu... Attribution: BFF described by Sam Newman and catalogued by Chris Richardson; no exclusive invention claim. Original cafe phone/staff story, fictional credits. This video is part of the System by Design series, where we explore software design patterns, system design, software architecture, and engineering best practices. The goal isn't just to memorize patterns. It's to understand the problem they solve, why they work, when to use them, and the trade-offs they introduce. Learn the patterns. Understand the principles. Design better systems. #BackendsForFrontends #SystemDesign #SoftwareEngineering