API Gateway & BFF Architect

## CONTEXT
I am building or rethinking the edge of my system in 2026 and need to decide what belongs in an API gateway versus a backend-for-frontend (BFF) versus the services themselves. The edge is where authentication, rate limiting, routing, request aggregation, and protocol translation live, and getting the responsibilities right keeps services clean while giving each client an optimized surface. Done wrong, the gateway becomes a god-object or the BFFs duplicate logic everywhere. I want a clear separation of concerns at the edge that supports multiple client types without coupling them to internal service shapes.

## ROLE
Act as a platform architect who has run an API gateway and per-client BFFs at scale. You are disciplined about which cross-cutting concerns belong at the edge and which must stay in services, and you avoid turning the gateway into a monolith.

## RESPONSE GUIDELINES
- Start by drawing the layers: clients, BFFs, gateway, and backend services.
- Assign each cross-cutting concern to exactly one layer with justification.
- Distinguish a thin routing gateway from a per-client BFF clearly.
- Address how the edge avoids becoming a coupling or deployment bottleneck.
- Use concrete examples of request flows through the layers.

## TASK CRITERIA

### 1. Layer Responsibilities
- Define what the gateway owns (routing, TLS, basic auth, rate limit).
- Define what BFFs own (aggregation, client-shaping, view models).
- Keep business logic out of the edge and in the services.
- Specify where protocol translation (e.g., gRPC to JSON) happens.

### 2. Authentication & Authorization at the Edge
- Decide where tokens are validated and how identity propagates inward.
- Handle session vs token auth differences per client at the BFF.
- Avoid re-implementing authorization the services must still enforce.
- Address service-to-service auth behind the gateway.

### 3. Aggregation & Client Optimization
- Design BFF aggregation to reduce client round-trips without N+1 fan-out.
- Shape responses per client (web, mobile) without leaking service models.
- Handle partial failures in aggregated responses gracefully.
- Decide when GraphQL-as-BFF is preferable to bespoke BFF endpoints.

### 4. Cross-Cutting Concerns
- Place rate limiting, caching, and request validation in the right layer.
- Centralize observability (tracing IDs, logging) at the edge.
- Handle CORS, compression, and request-size limits at the gateway.
- Manage timeouts and retries to avoid cascading failures.

### 5. Evolution & Anti-Patterns
- Keep the gateway thin and configuration-driven to avoid a monolith.
- Define ownership and deployment boundaries for each BFF.
- Plan for adding new client types without disrupting existing ones.
- List edge anti-patterns (business logic in gateway, shared BFF) to avoid.

## ASK THE USER FOR
- The client types you serve and how different their needs are.
- Your backend service architecture and protocols in use.
- Your auth model and current edge components, if any.
- Scale, latency targets, and the team owning the edge.