For an API edge that serves both public and private endpoints, the pattern that usually makes the most sense is a hybrid API gateway setup:

Recommended pattern: Single edge gateway + segmented routes/policies

Use one logical gateway layer at the edge, but separate behavior by route, audience, and trust level.

How it works

• Public APIs

  • Exposed on public domain(s)
  • Strong authN/authZ
  • Rate limiting, quotas, bot protection
  • Request validation, WAF integration
  • Caching where appropriate
  • Strict observability and abuse controls

• Private APIs

  • Not publicly reachable, or reachable only via VPN/private network/mTLS
  • Internal auth, service identity, stricter network controls
  • Different rate limits and maybe no CORS
  • Potentially higher trust in callers, but still enforce auth and schema checks

Why this pattern works well

• One operational surface for logging, analytics, policy, and routing
• Different security postures per endpoint class
• Easier to enforce consistent controls than with many ad hoc ingress points
• Lets you evolve from monolith edge to more specialized gateways later

---

Variants to consider

1) Single shared gateway with route-based policy

Best when:

• You want simplicity
• Public/private traffic can be separated cleanly by route and auth policy
• Same platform/team manages both

Typical setup:

• /public/* → public policy chain
• /private/* → private policy chain
• Same gateway, separate listeners or hostnames

2) Two gateways: public gateway + private/internal gateway

Best when:

• Security/compliance requires hard separation
• Different teams own public vs internal APIs
• Private APIs should never share an ingress plane with internet traffic

Typical setup:

• Public gateway
  • Internet-facing
  • WAF, DDoS protection, throttling, auth
• Private gateway
  • Internal network only
  • mTLS, service-to-service auth, internal routing

This is often the better choice for larger organizations or sensitive workloads.

3) BFF (Backend-for-Frontend) plus internal gateway

Best when:

• You have multiple clients (web, mobile, partner)
• You want client-specific APIs at the edge
• Public endpoints differ a lot from internal service APIs

Pattern:

• Public clients talk to a BFF/API gateway
• BFF composes internal services through a private gateway/service mesh
• Keeps public API surface smaller and more stable

---

Practical recommendation

If you’re starting out, choose:

Public internet-facing gateway + private internal gateway

This is the safest and cleanest separation if you truly have both public and private endpoints.

If you need faster delivery or lower ops overhead:

Single gateway with separate hostnames/routes and strict policy separation

Example:

• api.example.com for public
• internal-api.example.local or private DNS for internal
• Separate auth, logging, and rate-limit policies per host/route

---

Key design rules

Regardless of pattern:

• Never rely on path alone for trust boundaries
  • Use network boundaries, hostnames, mTLS, identity, and policy
• Separate auth models
  • Public: OAuth2/OIDC, API keys, signed requests
  • Private: mTLS, workload identity, IAM-based auth
• Use different rate limits and abuse controls
• Validate schemas at the edge
• Log and trace consistently
• Avoid mixing “internal-only” semantics into public routes

---

A simple decision guide

• Need strong separation / compliance? → Two gateways
• Need simplicity and moderate scale? → Single gateway with segmented policies
• Need client-specific aggregation? → BFF + internal gateway
• Need microservice-to-microservice control? → API gateway at edge + service mesh internally

If you want, I can sketch a reference architecture for:

1. Kubernetes,
2. cloud-managed gateway (AWS/GCP/Azure), or
3. self-hosted (Kong/NGINX/Envoy/Traefik).