Client to Orchestrator

When a user sends a message from the mobile app, the request passes through several infrastructure components before it reaches the Go orchestrator.

In plain language, this page answers: "What sits between the user and the backend, and what does each layer do?"

Each hop has one main job: find the right address, accept the internet traffic, decrypt it, check auth, and pass the request to the backend.

The Request Path

Let's walk through each hop in the same order the request sees it.

1

Step 1

Resolve DNS in Cloudflare

The mobile app sends an HTTPS request to dev.api.crawbl.com. Cloudflare answers the basic question, "which public IP should this hostname use?"

Crawbl uses external-dns to keep those DNS records updated automatically.

2

Step 2

Hit the cloud load balancer

The cloud load balancer is provisioned automatically by Envoy Gateway.

Its job is simple: provide a stable public entry point and forward traffic to the gateway pods. It does not inspect the request body or auth details.

3

Step 3

Terminate TLS and enforce auth at Envoy

Envoy Gateway is where encrypted internet traffic becomes readable HTTP inside the cluster.

This is also where security checks happen:

• HMAC validation for mobile X-Token requests
• JWT validation for Authorization: Bearer requests

If either check fails, the request is rejected here and never reaches the backend.

4

Step 4

Match the HTTPRoute

Envoy uses Kubernetes Gateway API HTTPRoute resources to decide which backend service should receive the request.

In plain language, this is the routing layer that says, "requests with this host and path go to this service."

5

Step 5

Hand off to the orchestrator

The Go orchestrator receives a normal HTTP request with trusted identity headers already attached.

From here, the request moves through the layered architecture: handler to service to repo to database.

Key Infrastructure Components

Component	Role
API Gateway (Envoy)	Gateway API implementation, TLS termination, auth filters
Certificate management	Automatic TLS certificates via DNS validation
DNS automation	Keeps public DNS records in sync with gateway hostnames

Why This Design

You might wonder why there are so many hops for a simple API call. Each component has a focused job:

• Cloudflare gives you global DNS with DDoS protection
• The LoadBalancer provides a stable public IP that survives pod restarts
• Envoy Gateway handles TLS and auth at the edge, so the orchestrator only sees pre-validated requests
• HTTPRoutes let you add new services without touching the load balancer

This separation means you can swap any component independently. Changing cloud providers? Replace the LoadBalancer type. Switching auth providers? Update the SecurityPolicy. The orchestrator code does not change.

What's Next

Now that the request has reached the orchestrator, see Orchestrator to Runtime to follow it to the ZeroClaw agent pod.