边缘计算是在地理上靠近用户的边缘位置处理请求的技术，Cloudflare Workers、AWS CloudFront Functions、AWS Lambda@Edge、Fastly Compute@Edge、Vercel Edge Functions 等平台是其代表。短链接的处理由于一次重定向即可完结，性质上很适合在边缘执行，可以低成本构建从世界各地都能在数毫秒内响应的短链接服务。
边缘执行的优点有三个。第一是延迟，在东京、大阪、新加坡、法兰克福等超过 200 个据点的边缘处理，让用户在 50 毫秒以内得到响应成为现实。第二是成本，Lambda@Edge 每 100 万次请求 $0.60，CloudFront Functions 为 $0.10，Cloudflare Workers 为 $0.50，这种按量计费比持有常设的计算节点便宜得多。第三是可用性，边缘执行不易受单一区域故障的影响，99.99% 以上的服务等级协议是现实可行的。
与一致性之间的取舍，是边缘执行的主要论点。短链接的重定向目标数据会通过键值存储 (Cloudflare Workers KV、DynamoDB Global Tables、D1) 在边缘做分布式复制，但从写入到传播至全世界会产生数秒到数十秒的延迟。可能出现刚发行新短链接之后，在世界上某些边缘还命中不到的情况。能否容忍这一点，决定了架构选择的分岔。
如果需要强一致性，在边缘做一级缓存判定、未命中时向源站 (中央数据库) 查询的构成更为现实。例如在 AWS 上，流程是由 CloudFront Functions 检查短代码缓存，未命中时从 Lambda@Edge 向 DynamoDB Global Tables 查询，再把源站的响应反映到 CloudFront 缓存中。刚发行之后会有些许延迟，但数分钟内就会在全世界切换为高速响应。
运营上的陷阱是边缘环境难以调试。边缘执行会按每个请求在不同位置处理，很难构建可复现的执行环境，因此需要把错误日志的汇总、指标和链路追踪集中到一处的可观测性设计。支持 OpenTelemetry 并汇总到 Datadog 或 Honeycomb 的构成，对稳定运营不可或缺。
地理路由作为边缘执行的应用非常强大。对同一条短链接，可以按用户的国家、设备、语言返回不同的跳转目标。为应对 GDPR 只把欧盟地区引导到另一个页面，向日语用户返回日语版商品页面，在 iOS 上深度链接到 App Store 而在 Android 上跳转到 Play Store，这些用途都会大幅提升短链接的附加价值。
使用边缘计算的短链接，在延迟、成本、可用性上全面优于传统构成。把握一致性的取舍、调试以及地理路由的运用要点，就能切实构建出全球范围内又快又便宜又稳定的短链接服务。