TL;DR
Fuse API Hub is a subscription-aware, policy-driven gateway that treats request admission as an economic and correctness boundary. Every incoming request is evaluated against identity, access rules, usage limits, and failure guarantees before it reaches upstream vendors. The system prioritizes predictable behavior, bounded failure modes, and operational simplicity over stateless abstractions or generic gateway patterns. The sections below describe the constraints and decisions that shape this design, while the deep dives explore how individual subsystems enforce these guarantees.
System Invariant
The gateway must never forward a request unless it is validated, authorized and within the active subscription’s usage limits. This invariant must hold even in the presence of partial failures, cache inconsistencies, or upstream instability. When this invariant cannot be guaranteed, the gateway fails closed.
System Context
Fuse API Hub sits between client applications and third-party vendor APIs. Clients issue requests using a single API key and logical endpoint, while the gateway resolves, authorizes, and forwards the request to the correct upstream provider.
The gateway owns authentication, subscription enforcement, request routing, rate limiting, caching, and response normalization. Vendor APIs remain unaware of consumers, plans, or access rules.
Why This Is Hard
This gateway is not a stateless reverse proxy. Each request must be evaluated against the client’s active subscriptions, allowed endpoint groups, rate limits, and quota state before any upstream vendor can be selected.
Routing decisions are therefore stateful and time-dependent. Subscription plans can change, renew, or expire, but access rules must remain consistent for the lifetime of an active subscription. These constraints make naïve REST abstractions insufficient and force access control, routing, and usage enforcement to live inside the gateway.
Core Requirements
- Act as a single, stable integration point for client applications
- Authorize each request based on the client’s active subscription state
- Determine the correct upstream endpoint for an authorized request
- Enforce usage limits consistently across clients and endpoints
- Preserve backward compatibility for active client integrations
Technical Constraints
- p95 latency under 100 ms for cached request paths
- Rate limiting and quota enforcement must work across multiple gateway instances
- Gateway state is distributed and cannot rely on in-memory coordination
- Small team with limited operational bandwidth
- Cost-aware design, with Redis, Kafka, PostgreSQL and compute as primary cost drivers
Architecture Overview
Requests enter the gateway, where authentication and subscription access are evaluated first. Authorized requests are routed, rate-limited and hits the vendors' backend.
The gateway owns access control and request resolution so client behavior remains consistent across providers.