---
title: How a request flows
sort: 1
---

# How a request flows

A `POST /v1/checkouts` from a storefront in Berlin to the `eu-frankfurt` region, with timings
representative of what we see at p50.

```drawio
{"meta":"placeholder — this fenced block is rendered by the drawio escape hatch on the live server. The local app exposes an in-app editor for it."}
```

The hops:

1. **Storefront SDK** issues the HTTPS request. (~1 ms TLS terminate, browser-side.)
2. **Edge** (Cloudflare in the user's POP, Frankfurt for Berlin) does WAF + DDoS, holds the
   connection. (~3 ms.)
3. **Regional load balancer** routes to the API gateway. (~1 ms.)
4. **API gateway** authenticates the bearer token, applies rate limits, attaches the tenant
   context. (~2 ms.)
5. **Checkout service** validates the cart, calls Tax and Inventory in parallel, persists the
   session, signs the hosted-checkout URL. (~30 ms — the bulk of the budget.)
6. **PostgreSQL** writes the checkout session, commits. (~5 ms within the region.)
7. **Response** travels back through the gateway → LB → edge → SDK. (~5 ms aggregate.)

End-to-end p50 from Berlin is ~50 ms. p99 is dominated by tax calculation and ranges 80–140 ms.

## What can go wrong at each hop

| Hop                | Failure mode                          | What we do                                       |
|--------------------|---------------------------------------|--------------------------------------------------|
| Edge               | DDoS                                  | Cloudflare absorbs; legit traffic unaffected     |
| Gateway            | Rate limit exceeded                   | Return 429 with `Retry-After`                    |
| Checkout service   | Tax service down                      | Fail open with a stub, flag the order for review |
| PostgreSQL primary | Failover (rare, ~30 s)                | Gateway returns 503 with `Retry-After: 5`        |
| Response back      | Network blip                          | SDK retries idempotently                         |