advanced
Slow in Frankfurt, Fine in Virginia
Read the evidence before you read the options. The signals are presented the way a dashboard would present them — nothing is labelled with the answer.
The report
European customers say the dashboard is slow. American customers say it is fine. The team has checked the EU deployment thoroughly and found nothing wrong — CPU, memory and database metrics are all healthy in both regions, and the EU instances are the same size as the US ones.
The system
Dashboard load — by client regionILLUSTRATIVE
| Signal | Value | What it tells you |
|---|---|---|
| p95 page load, US clients | 740 ms | American users see the page in under a second. |
| p95 page load, EU clients | 3.9 s | European users wait more than five times as long. |
| Server-side request duration | 148 ms (both regions) | Time measured inside the API is identical regardless of where the client is. |
| API instance CPU (both regions) | 22% | Compute capacity is not constrained anywhere. |
| Database query time (p99) | 14 ms | Queries execute quickly. |
| Requests per page load | 6 | Rendering the dashboard requires six separate API calls. |
| RTT, EU edge → us-east-1 | 88 ms | A round trip across the Atlantic takes about ninety milliseconds. |
| RTT, us-east-1 → eu-central-1 | 92 ms | The API's own database is a further ninety milliseconds away from it. |
Trace, one dashboard API call originating from an EU browser
GET /api/dashboard/summary 612 ms ├── [network] EU edge → us-east-1 API 91 ms ├── auth.verify (us-east-1 → us-east-1) 6 ms ├── db.query widgets (us-east-1 → eu-central-1) 108 ms │ └── pg.execute 13 ms ├── db.query metrics (us-east-1 → eu-central-1) 104 ms │ └── pg.execute 11 ms ├── db.query alerts (us-east-1 → eu-central-1) 101 ms │ └── pg.execute 9 ms ├── serialize 8 ms └── [network] us-east-1 → EU edge 89 ms
What is the constraint?