Do I need an API gateway to expose services safely to customers?

Not necessarily. An API gateway is one common way to expose services safely, but it’s not strictly required.

You might want an API gateway if you need:

• Authentication/authorization in one place
• Rate limiting / throttling
• Request routing to multiple backend services
• TLS termination
• Logging, monitoring, analytics
• Caching
• Versioning and consistent API management
• A single public entry point instead of exposing many services directly

You may not need one if:

• You have a small number of services
• A single service can be safely exposed with:
  • proper auth
  • HTTPS
  • network isolation
  • WAF / firewall rules
  • input validation
• Your “customer-facing” layer is already handled by a web app backend or BFF (Backend for Frontend)
• You’re using a managed platform that already gives you gateway-like features

Common safer alternatives

• Reverse proxy (e.g., Nginx, Envoy)
• Load balancer + WAF
• Backend-for-Frontend (BFF)
• Service mesh for internal service-to-service protection
• Managed API management services if you don’t want to operate one yourself

Rule of thumb

If customers will call multiple services directly, or you need centralized control/security, an API gateway is often a good idea.
If customers only need access to one well-designed API and security requirements are straightforward, you may not need one.

If you want, I can help you decide based on your architecture (number of services, auth needs, public vs internal APIs, cloud/on-prem).