Do I need a centralized API gateway for rate limits and auth across multiple teams?

Not always — but often yes for consistency, especially if multiple teams are exposing APIs to shared consumers.

When a centralized API gateway helps

Use one if you want:

• Consistent auth: one place to enforce OAuth/JWT/API key validation, scopes, tenant checks, etc.
• Shared rate limiting: per user, per client, per org, or per route across all teams.
• Uniform policies: logging, tracing, headers, CORS, request/response limits, WAF rules.
• Simpler consumer experience: one entry point, one contract.
• Operational control: easier to patch, audit, and monitor security policies.

When you might not need one

A centralized gateway may be unnecessary if:

• Teams are fully independent and own their own clients and policies.
• APIs are mostly internal service-to-service with service mesh/mTLS already handling auth/routing.
• You’re at a small scale where a gateway adds more process than value.
• Different products need very different throttling/auth rules, making a single gateway too rigid.

Common middle-ground approach

Many organizations do this:

• Central platform team owns the gateway framework/policies
• Product teams configure routes and app-specific rules
• Enforcement is centralized, but day-to-day changes are delegated

This avoids “everyone builds their own auth/rate-limit logic” without creating a bottleneck.

Good rule of thumb

If you have:

• 3+ teams,
• shared external consumers,
• compliance/security requirements,
• or repeated auth/rate-limit bugs,

then a centralized gateway is usually worth it.

If you want, I can also give you a decision matrix or a recommended architecture split between gateway, service mesh, and app-level auth.