🏛️
Section 10.3
BFF & Channel Patterns
Backend for Frontend patterns and digital channel architecture for telco.
Modern telcos serve customers through multiple channels: self-service portals, mobile apps, retail stores, contact centres, partner APIs, and chatbots. Each channel has different data requirements, performance profiles, and user experiences. The Backend for Frontend (BFF) pattern is the architectural response to this reality.
Backend for Frontend (BFF)
A BFF is a server-side component that sits between a specific frontend channel and the backend APIs. It aggregates, transforms, and optimises data from multiple backend systems into a shape tailored for that specific channel. Each channel (web, mobile, retail, partner) may have its own BFF.
What BFFs Solve
Without vs With BFF
| Problem | Without BFF | With BFF |
|---|---|---|
| Over/under-fetching | Mobile app receives 50 fields when it needs 5, or makes 4 calls for one screen | BFF returns exactly what the channel needs in a single optimised call |
| Backend coupling | Every backend API change requires updates to all frontends | BFF absorbs backend changes — frontends only change when their BFF contract changes |
| Channel-specific logic | "Show upgrade options" logic duplicated across web, mobile, and retail | BFF encapsulates channel-specific logic in one place |
| Security | Frontend directly calls domain APIs, requiring complex token exchange | BFF acts as a trusted intermediary with service credentials |
BFF Architecture Patterns
BFF Pattern Options
| Pattern | How It Works | Best For | Watch Out |
|---|---|---|---|
| One BFF per channel | Each channel (web, mobile, retail) has its own dedicated BFF service | Large telcos with dedicated channel teams | Code duplication across BFFs — mitigate with shared internal libraries |
| Shared BFF + adapters | Single BFF with channel-specific adapter layers | Small operators with limited teams | Coupling risk — a mobile change can accidentally break web |
| GraphQL as universal BFF | Single GraphQL API where each frontend queries exactly what it needs | Complex interactive UIs, teams with GraphQL expertise | Caching complexity, N+1 query problems, resolver orchestration overhead |
Recommended Approach
For Tier-1/2 operators: one BFF per channel, owned by the channel team. For smaller operators: shared BFF or GraphQL. Many telcos use REST between backend services (TMF APIs) and GraphQL between BFF and frontend.
API Gateway vs BFF vs Experience API
Three Distinct Layers
| Layer | Purpose | Owner | Business Logic? |
|---|---|---|---|
| API Gateway | Route, secure, and rate-limit API traffic | Platform / infrastructure team | None — pure infrastructure |
| BFF | Aggregate and transform data for a specific channel | Channel team (web, mobile, etc.) | Channel-specific aggregation and caching |
| Experience API | Shared cross-channel business logic (e.g., "Customer 360") | Integration / product team | Cross-channel logic shared by multiple BFFs |
Common Mistakes
Four Mistakes to Avoid
1. Frontend calls domain APIs directly — TMF APIs are designed for system-to-system integration, not frontend consumption. Always use a BFF.
2. Single BFF for all channels — becomes a "god service" and deployment bottleneck.
3. Business logic in the BFF — "Can this customer upgrade?" belongs in the catalog or eligibility engine, not the BFF. BFFs aggregate and transform, they do not make business decisions.
4. Ignoring offline/degraded modes — mobile BFFs must support cached responses, optimistic updates, and retry queues.
Section 10.3 Key Takeaways
- BFFs sit between frontends and backend domain APIs, aggregating and transforming data for each channel
- API Gateway handles infrastructure (routing, auth); BFF handles channel aggregation; Experience API handles shared cross-channel logic
- For large telcos: one BFF per channel. For small telcos: shared BFF or GraphQL.
- Never expose TMF domain APIs directly to frontends
- BFFs should aggregate and transform, not implement core business logic