Microservices With One Public API Domain

The short answer: One public API domain reduces client complexity and gives you one place to control auth, CORS, path policy, and service composition.

When to read this

• You already split services internally but want a simpler client contract.
• You need a cleaner migration path from monolith to multiple services.
• You want central edge policy enforcement.

What matters in practice

• Expose stable client paths even if internal service ownership changes.
• Use upstream aliases so route config stays readable.
• Keep service boundaries visible in docs even when the client sees one hostname.

Concrete example

        {
        "servers": [
          { "alias": "users", "url": "https://users.example.com" },
          { "alias": "orders", "url": "https://orders.example.com" }
        ],
        "paths": [
          { "method": "GET", "path": "/api/users/{.+}", "integration": { "type": "http_proxy", "server": "users" } },
          { "method": "GET", "path": "/api/orders/{.+}", "integration": { "type": "http_proxy", "server": "orders" } }
        ]
      }

The example above is intentionally small because the best gateway configs stay readable. Add only the route, auth, and mapping behavior you actually need.

How this maps to the current gateway

The current codebase already supports the behavior discussed here through its config schema, route matcher, and integration handlers. That is why this project is a good fit for reader-first examples: the docs and blog can point to real, implemented behavior instead of hypothetical gateway features.

What this product does not do

• One public domain does not remove the need for internal ownership and service documentation.
• The gateway does not implement multi-region origin failover policies.

FAQ

Can clients still call services directly?

They can, but you lose the simplification and policy centralization that the gateway provides.

Should every internal route be public?

No. Publish only the routes that belong in the client-facing contract.

Related docs

• routing multi upstream patterns
• backend for frontend with cloudflare workers
• api gateway patterns for internal tools

Last reviewed: March 6, 2026