Why Does One App Need Multiple Backends

Imagine you're building an e-commerce platform. You have: 📱 A mobile app 💻 A web application ⌚ A smartwatch app

All three need the same customer data. So should they all call the same backend APIs?

At first, that sounds reasonable. Until reality gets in the way. The web application needs detailed product information. The mobile app needs smaller payloads to reduce network usage. The smartwatch only needs order status.

If every client consumes the same APIs, one of two things usually happens:

• Clients receive far more data than they need.
• Or backend APIs become increasingly difficult to evolve without breaking someone.

That's where the Backend for Frontend (BFF) pattern comes in. Instead of one generic backend serving everyone, each client gets a backend tailored to its needs.

• Mobile BFF
• Smaller payloads
• Optimized for slower networks
• Web BFF
• Richer data
• Aggregates multiple services into a single response
• Wearable BFF
• Minimal data
• Battery-conscious responses

One thing I like about this pattern is that it optimizes for teams as much as technology. Frontend teams can evolve their APIs independently. Backend services stay focused on business capabilities. Clients receive exactly what they need.

It's a good reminder that architecture isn't always about adding complexity. Sometimes it's about moving complexity to the right place.