API gateway + MuleSoft proxies over internal services

Internal backend services spoke an RPC dialect through a bridge, and calling one meant a three-step auth sequence: get an OAuth token, sign in to mint a JWT, then attach that JWT to every downstream call. Every consumer reimplemented it, usually wrong.

I designed the data mesh API layer and built MuleSoft proxy APIs over three internal services: accounts and auth, the job scheduler, and ad inventory. The proxy does the OAuth exchange and JWT minting server-side, forwards to the right backend, and normalizes the bridge's responses into plain JSON, so a consumer sends one REST request instead of three. Shipped across dev, QA, and prod with GitLab CI/CD and per-environment routing. I also prototyped a unified GraphQL schema for sourcing and joining data products by field, and a proxy over the Snowflake SQL API as a single entry point.

The data-mesh API layer: proxy APIs that turn an internal RPC dialect and a three-step auth flow into one authenticated REST call.

I designed the API layer and built the proxies over three internal services.

• MuleSoft proxies in front of an accounts/auth service, the job scheduler, and ad inventory.
• The proxy runs the OAuth exchange, mints the JWT, forwards to the right backend, and unwraps the RPC response into plain JSON.
• Shipped across dev, QA, and prod through GitLab CI/CD, with honest per-environment routing.
• Prototypes: a unified GraphQL schema over the data products, and a proxy over the Snowflake SQL API.

• One REST call replaces a three-step sign-in every consumer used to reimplement.
• Auth, rate limiting, and logging live in one place instead of scattered across callers.
• A single entry point a consumer can use without knowing which backend it hits.