Best Kong Gateway pattern for an anonymous public calculator API behind Cloudflare?

Questions
1

I am evaluating Kong Gateway for a small public API that would sit behind an interactive website calculator.

This is the current browser-based user flow:

Disclosure: I maintain the linked website. There is no Kong-backed API on this page yet. I am sharing it only to show the real public application and traffic pattern I am planning for.

The page currently supports two operations:

  1. Calculate a result from a birth date

  2. Look up the interpretation of a number entered by the visitor

I am considering moving the shared logic and content behind a small stateless API.

The proposed endpoints are:

POST /v1/angel-numbers/calculate
GET  /v1/angel-numbers/{number}

Example request:

{
  "birthDate": "1995-09-27"
}

Example response:

{
  "number": 6,
  "type": "single_digit",
  "title": "Angel Number 6",
  "summary": "A short public interpretation",
  "canonicalUrl": "https://deckaura.com/example"
}

The planned request path is:

Browser
  -> Cloudflare
  -> Kong Gateway
  -> Stateless calculation API
  -> Content database or cache

The API would be publicly accessible from the website without user accounts or API keys.

My main requirements are:

  • Only approved website origins should be accepted by browsers

  • Anonymous abuse should be rate limited

  • Rate limiting should use the actual visitor IP

  • Public number lookups may be cached

  • Birth-date calculation responses should not be cached publicly

  • Invalid dates and unsupported numbers should be rejected consistently

  • Birth dates should not appear in ordinary access logs

  • Internal editorial endpoints should use separate authentication

  • One failing upstream instance should not make the complete API unavailable

  • Configuration should be reproducible through version-controlled files

I would appreciate guidance on the following points.

1. Where should anonymous rate limiting happen?

Would you normally apply rate limiting at both Cloudflare and Kong?

My current idea is:

  • Cloudflare for obvious bot and volumetric traffic

  • Kong for route-specific application limits

  • The upstream application for only the most important business constraints

Would this be unnecessary duplication, or is defence in depth normal for this kind of public endpoint?

2. Trusting the visitor IP

Because Kong would receive requests from Cloudflare, the direct source IP would normally be a Cloudflare address.

What is the recommended configuration for allowing Kong’s rate-limiting plugin to use the real visitor IP without blindly trusting a spoofable header?

Should Kong trust the forwarded client-IP header only when the request originates from Cloudflare’s published proxy ranges?

3. Route-specific limits

The two endpoints have different traffic characteristics.

For example:

POST /v1/angel-numbers/calculate
20 requests per minute per visitor

GET /v1/angel-numbers/{number}
100 requests per minute per visitor

Would you configure separate Routes connected to the same Service and attach a different rate-limiting plugin instance to each Route?

I may also want stricter limits for invalid or repeatedly changing inputs.

4. Anonymous users behind shared networks

IP-based limits can affect several legitimate users behind a school, company, mobile carrier or VPN.

For a public browser tool with no authentication, is there a better identifier than IP?

I have considered combining:

  • IP address

  • A first-party anonymous session cookie

  • A short-lived signed visitor identifier

However, I do not want the rate-limiting system to become a tracking mechanism or depend entirely on client-controlled values.

5. CORS ownership

Would you configure CORS only in Kong and remove the equivalent headers from the upstream application?

The expected browser origin would be:

https://deckaura.com

Preview and local development environments would also need access.

I want to avoid duplicated or conflicting CORS headers being added by Cloudflare, Kong and the upstream service.

6. Preflight requests

Should OPTIONS requests be excluded from rate-limit accounting?

A browser could otherwise consume part of the visitor’s quota through preflight traffic rather than actual calculator requests.

Is this normally handled by the CORS plugin automatically, or should the preflight path be routed separately?

7. Caching public lookup responses

Responses from:

GET /v1/angel-numbers/444
GET /v1/angel-numbers/777

would change rarely and could probably be cached.

The calculation endpoint receives a birth date and should not be stored in a shared proxy cache.

Would you attach caching only to the GET Route and explicitly return:

Cache-Control: no-store

from the POST endpoint?

I am also deciding whether caching belongs in Kong, Cloudflare or both.

8. Request validation

The calculation endpoint should reject:

  • Missing birth dates

  • Impossible dates

  • Unexpected JSON properties

  • Excessively large bodies

  • Unsupported content types

  • Future dates, depending on the final product rule

Would you enforce the basic request schema in Kong and keep domain rules in the application?

For example, Kong could verify the content type, body size and JSON shape, while the application determines whether a date is acceptable.

9. Protecting internal routes

The same upstream may later expose editorial endpoints such as:

PUT /v1/internal/angel-numbers/{number}
POST /v1/internal/cache/purge

Would you normally expose these through the same Kong Service with separate Routes and authentication plugins, or create a completely separate Service and hostname?

I would prefer internal routes not to be reachable through the public hostname at all.

10. Logging and privacy

The birth date is required for the calculation, but I do not need it for analytics or troubleshooting.

Can Kong access logs be configured so that the request body is never recorded while still retaining:

  • Request ID

  • Route

  • Status code

  • Latency

  • Upstream status

  • Rate-limit result

  • Anonymous client identifier or truncated IP

I would also like a correlation ID to pass from Cloudflare through Kong to the upstream.

11. Upstream availability

The calculation service would initially have one instance, but I may later run two stateless instances.

Would a Kong Upstream with active health checks be appropriate even at this small scale?

If one target becomes unhealthy, the second target should receive new requests without clients seeing repeated 5xx responses.

12. DB-less or database-backed Kong

The initial configuration would be small:

  • One public Service

  • One internal Service

  • Four or five Routes

  • CORS

  • Rate limiting

  • Correlation IDs

  • Logging

  • Authentication for internal routes

Would DB-less mode with a version-controlled declarative configuration be the simplest deployment?

I do not expect runtime configuration changes from an admin interface. All changes could go through Git and CI.

13. Testing the configuration

Before production, I plan to test:

  • Valid and invalid origins

  • Spoofed forwarding headers

  • Shared-IP users

  • Rate-limit reset behaviour

  • Cloudflare and Kong limit interaction

  • Duplicate CORS headers

  • OPTIONS requests

  • Oversized JSON bodies

  • Upstream timeout and failover

  • Cache hits and invalidation

  • Internal route access without credentials

  • Removal of birth dates from logs

Is there a recommended Kong testing workflow for validating these behaviours in CI?

I am mainly looking for an architecture review before implementing the first version. The initial deployment would be self-managed Kong Gateway in front of a small stateless API.