When hosting an event where 200 guests simultaneously scan a QR code to access a shared digital gallery, the architectural challenge is not the complexity of the redirect, but the temporal density of the request spike. A naive implementation often relies on a centralized [database](/blog/your-cache-expired-and-the-database-spiked-four-fixes-for-cache-stampedes) to log every scan, which, under concurrent load, creates a bottleneck at the connection pool or the primary write node.

To ensure a seamless user experience, we must design for ‘thundering herd’ scenarios. When 200 devices hit your ingress controller at the same millisecond, the [system](/blog/designing-an-uber-style-ride-matching-system-a-deep-dive-into-geospatial-indexing-algorithms) must prioritize request throughput and cache-hit ratios over immediate persistent logging.

The Edge-First Routing Pattern

The most effective way to handle this volume is to move the redirection logic to the edge. By using a Content Delivery Network (CDN) or an Edge Worker, you can terminate the TLS handshake closer to the user and perform the redirection without hitting your origin server at all.

addEventListener('fetch', event => {
  const url = new URL(event.request.url);
  if (url.pathname === '/gallery/access') {
    return event.respondWith(Response.redirect('https://gallery.example.com/live', 302));
  }
  event.respondWith(fetch(event.request));
});

By offloading the 302 redirect to the edge, you reduce latency to the minimum possible RTT. The origin server remains untouched, preserving resources for the actual gallery application, which likely requires higher compute overhead for image rendering and asset delivery.

Handling Analytics and State

A common requirement is tracking how many users have scanned the code. Writing to a relational database on every request is an anti-pattern for this scale. Instead, implement an asynchronous event stream. Capture the scan event at the edge, push it to a message queue (like Redis or SQS), and aggregate the counts in the background.

Trade-offs in Eventual Consistency

• Use Redis INCR commands for atomic, high-speed counting.
• Buffer analytics events to avoid database write contention.
• Accept that the ‘real-time’ guest count may be delayed by a few seconds.

Infrastructure Resilience

When designing for a specific time-bound event, ensure your DNS TTL is set low (e.g., 60 seconds) well in advance. This allows for rapid failover if the primary ingress point experiences load issues. Furthermore, implement rate limiting at the WAF level to protect against accidental recursive scanning or malformed requests that could exhaust worker threads.

The goal of a high-concurrency QR system is to make the infrastructure invisible. If the user scans and lands on the gallery in under 200ms, the architecture is successful.

Conclusion

Scaling a QR code redirection system for 200 concurrent users is a matter of minimizing the work done at the origin. By leveraging edge computing for routing and decoupling analytics from the request-response cycle, you create a robust system capable of handling significantly higher traffic than the initial requirement. Simplicity at the entry point is the key to maintaining availability during peak event traffic.