エッジ上の動的 QR コードリダイレクトアーキテクチャ

動的 QR コードは、静か画像中に組み込まれた短 URL です。 「動的」部分はデータベースレコードであり、再印刷せずにスラッグと目的地のマッピングを更新できます。画像自体は決して変わりません。何か興味深いことは全てリダイレクトレイヤーで起こります。すべての読み取りが、ユーザーが次のアクションに進む前に解決されるライブな HTTP リクエストになります。以下に、そのレイヤーの姿、どのように適切に構築するか、そしてどこで破綻するかを示します。QR イメージには、go.yourcompany.com/r/abc123 などの固定文字列がエンコードされます。変わるのは abc123 を目的地 URL にマッピングするデータベースレコードだけです。すべての印刷された QR コードの信頼性は、そのリダイレクトサーバーの信頼性に正確に等しくなります。画像内のどこかがフォールバックとして機能しません。遅いサーバー = 遅いスキャン。ダウンしたサーバー = スキャン失敗。キャンセルされたアカウント = エラーページ。インフラこそが商品そのものです。カメラのタップから目的地までの全工程：スキャン：デバイスが QR パターンを読み取り、短 URL をデコード DNS 解決：リダイレクトドメインを最近的な IP (エッジ) または一つの固定 IP (シングルオリジン) に解決 TCP + TLS ハンドシェイク：50〜150ms の冷開始、距離とネットワーク状況に依存する HTTP GET: GET /r/abc123 がリダイレクトサーバーを叩く ロックアップ：サーバーがそのスラッグにマッピングされた目的地 URL をキャッシュや KV ストアで検索 アシンクロログ：応答をブロックせずにスキャンイベント（タイムスタンプ、IP、User-Agent）をクエリーにキューイング HTTP 302：Location ヘッダーを返し、ブラウザがリダイレクトを追従 目的地が読み込まれる ステップ 3〜7 はリダイレクトインフラが制御するものです。この時間がエッジコンピューティングが圧縮するものです。最もシンプルな実装：バージニア州またはフランクフルトにある一台のサーバー。世界のすべてのスキャンがそのボックスに達します。規模において表れる 2 つの問題があります。まずレイテンシです。シドニーからバージニア州まで、200 バイトのリダイレクト応答を受け取るのに 180ms の往復がかかっています。TCP 設定自体が既に 100ms かかった低速モバイルネットワークでは、目的地の読み込みが始まるまでに 300ms にかかってしまいます。次に単一の故障点です。悪質のデプロイ、DDoS、またはデータセンターの事故は、プラットフォーム上のすべての QR コードを一斉にオフラインにします。フォールオーバーする第二のリージョンがありません。多くの小型 QR プラットフォームはこの仕組みを正確に実行しています。ボリュームが低い間は問題ありません。問題は規模において現れ、その時点ではコードは既に印刷されています。エッジファーストはリダイレクトロジックをグローバルに分散したノードに移動させます。Cloudflare Workers と Fastly Compute は 200 か都市以上で JS/Wasm を実行します。DNS はアンカストを介して最近的なエッジノードに解決します。シドニーから最近的なエッジまでの TTFB は 150〜200ms から 5〜20ms になります。ノード内では、メモリーキャッシュや分散 KV から読み取ります。Cloudflare Workers KV は ~60 秒で書込みをグローバルにレプリケートし、どのノードからも単桁ミリ秒のレイテンシで読み取ります。1 つの KV リードだけです。結合付きデータベースクエリではありません。最小限の Cloudflare Worker リダイレクトハンドラー：export default { async fetch(request, env, ctx) { const slug = new URL(request.url).pathname.slice(3); // /r/ を除去 const destination = await env.REDIRECTS.get(slug); if (!destination) { return new Response("Not found", { status: 404 }); } // fire-and-forget、リダイレクトをブロックしない ctx.waitUntil(logScan(request, slug, env)); return Response.redirect(destination, 302); }, }; async function logScan(request, slug, env) { await env.SCAN_QUEUE.send({ slug, ip: request.headers.get("CF-Connecting-IP"), country: request.headers.get("CF-IPCountry"), ua: request.headers.get("User-Agent"), ts: Date.now(), }); } シングルオリジンエッジ TTFB（サーバーと同じリージョン）20〜40ms 5〜15ms TTFB（世界の反対側）150〜250ms 15〜30ms トラフィックスパイク下の P99 800ms〜2s+ 30〜60ms リージョン障害 100% のスキャンが失敗自動フォールオーバー、ユーザーへの影響なし 規模でのコスト垂直スケーリングアウト ペリクエスト応答常に 302（一時的なリダイレクト）のみ使用し、301（永久的なリダイレクト）を使用しないでください。ブラウザは 301 を激しくキャッシュします。ユーザーが以前スキャンした際に、ブラウザが古い目的地をキャッシュしていた場合、データベースを更新しても効果がありません。彼らはキャッシュの有効期限が切れるまで古い URL を得続けます。302 はブラウザにキャッシュをしないよう指示するため、すべてのスキャンがリダイレクトサーバーに新たに到達します。これは最も一般的なリダイレクトアーキテクチャのミスです。テスト中に不可視であり、繰り返しのスキャンでのみ現れます

A dynamic QR code is a short URL baked into a static image. The "dynamic" part is a database record: a slug-to-destination mapping you can update without reprinting. The image never changes. Everything interesting happens in the redirect layer. Every scan is a live HTTP request that has to resolve before a user moves on. What follows is what that layer looks like, how to build it right, and where it breaks. The QR image encodes a fixed string like go.yourcompany.com/r/abc123. What changes is the database record mapping abc123 to a destination URL. The reliability of every printed QR code is exactly equal to the reliability of that redirect server. Nothing in the image acts as a fallback. Slow server = slow scan. Down server = failed scan. Cancelled account = error page. The infrastructure is the product. Full sequence from camera tap to destination: Scan: device reads the QR pattern, decodes the short URL DNS resolution: resolves the redirect domain to nearest IP (edge) or one fixed IP (single-origin) TCP + TLS handshake: 50–150ms cold, depending on distance and network HTTP GET: GET /r/abc123 hits the redirect server Lookup: server checks cache or KV store for the destination URL mapped to that slug Async log: queues scan event (timestamp, IP, User-Agent) without blocking the response HTTP 302: returns Location: Browser follows the redirect Destination loads Steps 3–7 are what the redirect infrastructure controls. That window is what edge computing compresses. Simplest implementation: one server in Virginia or Frankfurt. Every scan in the world hits that box. Two problems surface at scale. Latency first. Sydney to Virginia is about 180ms round-trip just to receive a 200-byte redirect response. On a slow mobile network where TCP setup already costs 100ms, you're at 300ms before the destination even starts loading. Then there's the single point of failure. A bad deploy, a DDoS, or a data center incident takes every QR code on the platform offline at once. No second region to fail over to. Most small QR platforms run exactly this. Fine at low volume. Problems show up at scale, and by then codes are already printed. Edge-first moves redirect logic to globally distributed nodes. Cloudflare Workers and Fastly Compute run JS/Wasm at 200+ cities. DNS resolves via anycast to the nearest edge node. TTFB for Sydney to nearest edge: 5–20ms instead of 150–200ms. At the node, the lookup reads from an in-memory cache or distributed KV. Cloudflare Workers KV replicates writes globally within ~60s and reads with single-digit millisecond latency from any node. One KV read, not a database query with joins. Minimal Cloudflare Worker redirect handler: export default { async fetch(request, env, ctx) { const slug = new URL(request.url).pathname.slice(3); // strip /r/ const destination = await env.REDIRECTS.get(slug); if (!destination) { return new Response("Not found", { status: 404 }); } // fire-and-forget, doesn't block the redirect ctx.waitUntil(logScan(request, slug, env)); return Response.redirect(destination, 302); }, }; async function logScan(request, slug, env) { await env.SCAN_QUEUE.send({ slug, ip: request.headers.get("CF-Connecting-IP"), country: request.headers.get("CF-IPCountry"), ua: request.headers.get("User-Agent"), ts: Date.now(), }); } Single-origin Edge TTFB (same region as server) 20–40ms 5–15ms TTFB (opposite side of world) 150–250ms 15–30ms P99 under traffic spike 800ms–2s+ 30–60ms Regional outage 100% of scans fail auto-failover, zero user impact Cost at scale Vertical scale-out Per-request Always use 302 (temporary redirect), not 301 (permanent). 301 gets cached aggressively by browsers. If a user previously scanned and their browser cached the old destination, updating the database does nothing; they get the old URL until their cache expires. 302 tells browsers not to cache, so every scan hits the redirect server fresh. This is the most common redirect architecture mistake. Invisible during testing, only shows up for repeat visitors in production. Not every destination changes frequently. Cache the slug-to-destination mapping at the edge to skip the KV read on hot slugs. TTL of 30–120s covers most use cases. Fast enough for campaign changes, cheap at scale. Stale-while-revalidate serves the cached destination immediately and refreshes in the background: export default { async fetch(request, env, ctx) { const slug = new URL(request.url).pathname.slice(3); const cacheKey = `dest:${slug}`; const cached = await env.CACHE.get(cacheKey); if (cached) { // return immediately, refresh cache in background ctx.waitUntil( fetchFromOrigin(slug, env).then((dest) => dest ? env.CACHE.put(cacheKey, dest, { expirationTtl: 60 }) : null ) ); return Response.redirect(cached, 302); } const destination = await fetchFromOrigin(slug, env); if (!destination) return new Response("Not found", { status: 404 }); ctx.waitUntil(env.CACHE.put(cacheKey, destination, { expirationTtl: 60 })); ctx.waitUntil(logScan(request, slug, env)); return Response.redirect(destination, 302); }, }; Users never wait for cache misses. The miss penalty is invisible. Some use cases need different destinations per location. A global brand might send US users to a US landing page and EU users to a different one with localized copy and compliance language. A restaurant chain might send users to the nearest location's menu. Edge workers get geolocation headers on every request, no external API call needed. On Cloudflare, CF-IPCountry gives you the ISO country code. Store a slug:country key in KV and do the lookup in one read. export default { async fetch(request, env, ctx) { const slug = new URL(request.url).pathname.slice(3); const country = request.headers.get("CF-IPCountry") ?? "XX"; // try geo-specific destination first, fall back to default const destination = (await env.REDIRECTS.get(`${slug}:${country}`)) ?? (await env.REDIRECTS.get(slug)); if (!destination) { return new Response("Not found", { status: 404 }); } ctx.waitUntil(logScan(request, slug, country, env)); return Response.redirect(destination, 302); }, }; KV key structure: abc123 → default destination abc123:US → US destination abc123:DE → German destination One KV read for geo-specific, two reads for fallback. Still single-digit millisecond latency, no round-trip to a central routing service. It's more useful than it looks. Regional A/B tests, localized landing pages, GDPR compliance redirects: all of it becomes a KV write from the dashboard instead of a deploy. Writing to a database synchronously before returning the redirect is the worst architecture choice here. It puts a write operation (lock contention, index updates, network round-trip to a central DB) directly in the hot path of every single scan. Two patterns that work: Queue-based: the Worker sends a lightweight event to Cloudflare Queues or SQS and returns the redirect immediately. A separate consumer drains the queue, enriches events with geo-lookup and device parsing, and writes to the analytics store. If the pipeline backs up or errors, scans keep working. Edge streaming: log events go to Cloudflare Logpush, then object storage, then Kafka or Kinesis, then the analytics DB in batches. More infrastructure, but scales to millions of scans per day without per-event writes. Same principle either way: redirect response latency stays fixed. Analytics write latency is irrelevant to users. A redirect service has a short list of things worth tracking. Redirect TTFB by region: track P95 and P99, not average. Average hides tail latency that shows up for users on slow mobile networks. If P99 in Asia spikes to 800ms, something is wrong with KV replication or a regional node. Cache hit rate: a sudden drop means something invalidated the edge cache. Catch it before it becomes a latency regression. Scan error rate: 404s are expected for deleted slugs. 500s, timeouts, and connection resets need alerting. One bad deploy should not silently fail millions of scans. Queue depth: if the scan event queue is backing up, the analytics pipeline has a problem. The redirect still works, but lag accumulates. Left long enough, you'll either drop events or overwhelm the consumer when it catches up. In Cloudflare Workers, Workers Analytics Engine is a time-series store built for this pattern. Push a data point per request, query with SQL-like syntax via the Analytics Engine API. // inside fetch handler, non-blocking ctx.waitUntil( env.ANALYTICS.writeDataPoint({ blobs: [slug, country, request.headers.get("CF-Ray") ?? ""], doubles: [Date.now()], indexes: [slug], }) ); Query it later: SELECT blob1 AS slug, blob2 AS country, count() AS scans, quantilesMerge(0.95)(quantilesState(0.95)(double1)) AS p95_ts FROM SCAN_EVENTS WHERE timestamp > NOW() - INTERVAL '1' HOUR GROUP BY slug, country ORDER BY scans DESC One endpoint. No external observability stack in the hot path. When a node goes unhealthy, anycast DNS shifts requests to the next-nearest healthy one automatically. Latency ticks up slightly; the service stays up. With single-origin, one failure is a complete outage. The resilience pattern most people skip: stale-on-error. If the origin data store is unreachable, serve the last-cached destination instead of returning an error. Destination changes are rare; the cached value is almost always right. A slightly stale redirect beats an error page every time. The short URL encoded in a printed QR code is permanent. Once it's on packaging, signage, or business cards, you can't change it without reprinting. If that URL is qrtiger.io/r/abc123, every printed code's operational status is permanently tied to QR Tiger. Cancel the subscription and you get error pages. Platform shuts down, error pages. Price increase, you negotiate from zero leverage. Owning the redirect domain fixes this. go.yourcompany.com/r/abc123 can point at any infrastructure at any time. Update a DNS record to switch platforms or self-host. The printed codes never change; what's behind them does. Most QR platforms charge a premium for custom domains or don't support them at all. That's not incidental. A platform hosting your redirect domain has permanent leverage over materials that cost real money to replace. A self-hosted redirect on Cloudflare Workers costs about $5/month for the Workers subscription plus under $0.50/million redirect reads. The Worker is 50–100 lines. A few hours to deploy. What a platform adds: destination management UI, analytics dashboard, QR generation tooling, reliability guarantees. For teams without dedicated infra engineers, that management layer is the actual product. That's probably why most teams should buy rather than build. Either way: edge compute for the redirect hop, analytics out of the hot path, short-TTL caching with stale-while-revalidate, stale-on-error resilience, and a redirect domain you control. The QR image is just the entry point. The redirect layer is the product. I'm building QR Nova, a QR platform built on this architecture. Happy to answer questions in the comments.