Walk me through this one. An executive has read that a delivery network runs more than four thousand points of presence and wants product personalisation moved to the edge this quarter. You have fifteen minutes with them. What do you establish and what do you refuse?

What the interviewer is testing

Whether you can turn a location count into an architecture, and whether you will say no to a senior person holding a number. The number is real. Akamai's FY2025 annual report describes more than 4,300 edge points of presence in over 130 countries and roughly 700 cities as of 31 December 2025, across roughly 1,200 partner networks. A hyperscaler, by contrast, runs on the order of 30 to 40 regions.

The gradient that matters is not location count, it is capability per location: thousands of points of presence with a constrained runtime, tight CPU and memory limits and no primary database, against dozens of regions with the full service catalogue and a writable store.

The clarifying questions that change the answer

• What does the personalisation read? If the decision needs a 2 KB profile for any of 40 million users, replicating that to every location is 80 GB per site before indexes, times thousands of sites. If it needs a cohort identifier that fits in a signed cookie, the edge is the right place and the change is small.
• How stale may the decision be? Seconds is edge-compatible. Read-your-own-writes is not.
• What is the cacheability of the response? Personalised responses are low-hit-rate by definition, so the benefit has to come from compute at the edge, not from caching.
• Which jurisdictions may hold which data? A footprint spanning 130 countries is a data-residency surface before it is a latency asset.
• Who debugs it at 03:00? Edge platforms give you less: no shell on the host, sampled logs, limited local state, and a deploy model you do not control.

The arc of a strong answer

Give the executive three tiers they can repeat. At the point of presence: TLS termination, caching, routing, header and token work, bot checks, and any decision computable from the request plus a small slowly-changing dataset. In a region: the writable database, transactional work, inference that needs an accelerator. In one home region: anything that must be globally unique or strongly consistent.

Then commit to one slice this quarter: cohort assignment at the edge from a signed cookie, with the cohort computed in-region nightly. Report p50 and p99 for the personalised fragment and let the measurement decide whether anything else follows. Agreeing to a slice and a number is how you decline the quarter without declining the idea.

Common weak answers

• "Replicate the profile store to the edge." Price it in the room: profiles × size × locations, plus the write fan-out on every profile change. The arithmetic ends the proposal faster than an opinion does.
• "The platform's key-value store is globally replicated." Globally replicated means eventually. Ask the platform's documented convergence time and whether the product tolerates it.
• Saying yes and discovering the data problem in month two, which converts a design disagreement into a delivery failure.

What a strong answer adds

The operational asymmetry. A configuration change reaches thousands of points of presence in seconds, which means the edge is the one tier where a bad push has no natural blast-radius boundary unless you build one. Staged activation per location and a rollback measured in the same units as the push are harder requirements at the edge than in a region, and that cost belongs in the quarter's estimate alongside the feature.