Case Study: Designing the Edge for an Orders Platform

The design

Public traffic enters a cloud load balancer, then an API gateway (two or more instances across zones) that terminates TLS, validates API keys or JWTs, applies per-client rate limits (429 with Retry-After), generates a request ID, strips internal headers and routes by path to orders, users and payments. New releases use weighted canaries (5%, then 25%, 50%, 100%) with automatic rollback on error-rate or p99 regressions, after a mirrored-traffic trial. Inside the cluster, a mesh provides mTLS with short-lived identities, default-deny authorisation (only billing may call payments), timeouts that shrink with depth, retries only for idempotent calls at the mesh layer, circuit breaking and outlier detection, and telemetry for the golden signals with trace propagation. All config lives in Git, is validated in CI and rolled out gradually, with a tested emergency bypass and failure drills each quarter.

A guarded, observable entry point

Routing, auth, limits, resilience and telemetry combine into a dependable edge and a trustworthy mesh.

The design on one page

Each line maps to a section of this course.

Edge        LB -> 2+ gateways, TLS termination, request IDs      (Sec 1-2)
Routing     path routes, header opt-in canary, weighted 5/25/50/100  (Sec 2)
Security    API key/JWT at edge, per-client rate limits, WAF/CORS   (Sec 3)
Resilience  timeouts shrink with depth, retries at ONE layer,       (Sec 4)
            circuit breaker + outlier detection, consistent hashing
Mesh        mTLS identities, default-deny authz, telemetry + traces  (Sec 5)
Ops         config in Git + validation, staged rollouts, bypass,     (Sec 6)
            failure drills; no mesh unless the scale needs it
Delivery    mirror -> canary -> promote/rollback automatically       (Sec 7)

Quick check: In the design, where are retries performed and why?

• Nowhere
• At every layer for maximum safety
• At one layer, only for idempotent calls, to avoid amplification
• Only in the browser