API Gateway Patterns for Teams That Do Not Need Kong

Every architecture diagram we review from new clients has an API gateway box. When we ask what it does, the answer is rate limiting, authentication, and request routing. When we ask how many API consumers they have, the answer is usually just their frontend.

If you have a single frontend consuming a single backend, you do not need an API gateway. You need middleware. The distinction matters because API gateways are designed for managing multiple consumers with different access levels, rate limits, and routing rules. If your gateway routes all traffic from one frontend to one backend, you have a reverse proxy with extra steps.

Pattern one: middleware stack. For the majority of our projects, we implement gateway features as application middleware. Rate limiting with upstash/ratelimit and Redis. Authentication middleware. CORS handling. Request logging. These compose naturally, run in-process, require zero additional infrastructure, and total under 200 lines of code.

Pattern two: edge proxy with Cloudflare Workers. For projects needing multi-backend routing or A/B testing. A Worker script at the edge inspects requests, adds authentication headers, routes to different backends by path, and caches responses. We used this for a client with a Next.js frontend, Python ML backend, and Node.js payments service. Total cost: zero dollars within the free tier.

Pattern three: Caddy reverse proxy. For genuine API platform complexity with external consumers needing different access levels and rate limits. Caddy has built-in HTTPS, rate limiting, and authentication modules. Setup takes about a day, versus the week-plus we have seen teams spend configuring Kong or AWS API Gateway.

The anti-pattern we see repeatedly: premature gateway adoption. A team adds AWS API Gateway in front of a single Lambda function for future extensibility. They get a $30-50 monthly bill, additional latency on every request, a more complex deployment pipeline, and a new service to monitor. The extensibility never materializes.

Our framework: one consumer plus one backend equals middleware. One consumer plus multiple backends equals edge proxy. Multiple consumers with different access requirements equals dedicated proxy. The gateway you do not deploy is the gateway you never have to maintain at 2am.