API Gateway with Backends-for-Frontends
An edge API gateway centralizes authentication and rate limiting while channel-specific BFF services aggregate microservices for web, mobile, and partner clients. The design lets each client surface evolve independently on AWS managed services.
Overview
Large product surfaces serve many client types: a single-page web app, native mobile apps, and partner integrations. A shared general-purpose API forces every client through one contract, which becomes a compromise that fits none of them well. This reference architecture pairs an edge API gateway with a set of Backends-for-Frontends (BFF) services. The gateway handles cross-cutting concerns (TLS termination, authentication, rate limiting, routing), while each BFF tailors payloads and aggregation to one channel.
Use this design when clients have divergent data shapes, when mobile bandwidth matters, or when partner contracts must evolve independently from internal services.
Components
- CloudFront: edge CDN that caches static assets and terminates client connections close to users.
- API Gateway: routes requests, enforces rate limits, validates JWTs, and emits access logs.
- Cognito: issues and validates OAuth 2.0 / OIDC tokens for end users and partners.
- Lambda / ECS Fargate: host the BFF services. Lightweight web and mobile BFFs run on Lambda; the partner BFF, with steadier traffic, runs on Fargate.
- DynamoDB: stores BFF-owned read models and session data.
- ElastiCache (Redis): caches aggregated responses and rate-limit counters.
Data Flow
A client request hits CloudFront, then the API gateway, which authenticates the caller and routes to the matching BFF by path or host. The BFF fans out to downstream microservices over private networking, composes a channel-specific response, caches it in Redis when safe, and returns it. Write requests pass through to domain services; the BFF only orchestrates, never owning core business state.
Scaling and Resilience
Lambda-based BFFs scale per-request automatically; the Fargate partner BFF scales on CPU and request-count targets. Downstream calls use timeouts, retries with jitter, and circuit breakers so one slow service does not cascade. Read models in DynamoDB and Redis absorb spikes and keep the experience responsive during partial outages. Each channel can be deployed and rolled back independently.
Security
The gateway is the single ingress: it enforces OAuth 2.0 with OIDC, scoped tokens, and per-client rate limits. BFFs run in private subnets and reach downstream services only through internal endpoints. Secrets live in a managed secret store, and least-privilege IAM roles bound each function. Partner traffic is isolated to its own BFF with stricter quotas and audit logging.
Trade-offs and Alternatives
BFFs add deployable units and some duplicated aggregation logic, so the pattern pays off only when client needs genuinely diverge. A single shared API is simpler for one or two similar clients. GraphQL is an alternative when clients mainly differ in which fields they need rather than in orchestration logic; the two can coexist, with GraphQL behind a BFF.