Edge Computing for Truly Global Apps
When to push logic to the edge, when to keep it in region, and the consistency trade-offs we document for every client.
Edge is a latency tool, not a architecture religion
Pushing everything to the edge creates consistency headaches and debugging fog. Push the right things: static assets, personalisation that tolerates slight staleness, auth checks, and A/B routing.
Keep strongly consistent writes and complex transactions in regional systems of record. Document that split for every client so product expectations match physics.
What belongs at the edge
HTML shell rendering, bot mitigation, geo-routing, and cacheable API fragments are high-ROI. Heavy business logic with multi-row transactions usually is not.
Measure TTFB from real user regions before and after. Edge wins that only appear in a single synthetic probe are marketing, not engineering.
Consistency trade-offs to write down
Stale-while-revalidate, session affinity, and conflict windows should be explicit. Users in Sydney and Frankfurt will not see the same read-after-write behaviour unless you design for it.
We include a consistency appendix in architecture reviews: which data is edge-cached, TTLs, and invalidation paths.
Operational realities
Edge platforms constrain runtime, memory, and dependencies. Observability must stitch edge traces to origin traces or incidents become two half-stories.
Start with one high-traffic read path. Expand only after you have kill switches and clear ownership for cache poison and config rollout failures.
James Okonkwo
Platform Engineer
Platform engineer building event-driven systems, observability, and edge architectures.
