How to build a scalable dynamic QR redirect system? The complete architecture explained.

A dynamic QR system is more than a QR code generator. In this article I explain the full architecture of a scalable redirect system — from database structure to redirect engine and analytics.

A QR code is simple. A dynamic QR system is not.

The difference lies in what's behind the QR code. A static QR code points directly to a URL. Scan it, go there. Always. That's useful for simple applications, but it has a major drawback: if you want to change the destination, you need to create a new QR code and reprint it.

A dynamic QR system works differently. The QR code doesn't point to the final destination, but to a redirect engine. That engine determines, at the moment of scanning, where the user goes. The destination can be changed at any time — without reprinting the QR code.

That sounds simple. The implementation is not.

The database architecture

The core of a dynamic QR system is the database. You need at least three entities:

1. Tags — the QR codes themselves, with a unique code and a reference to the active redirect

2. Redirects — the destinations, linked to a tag

3. Scans — every scan is recorded with timestamp, device, location and tag

A tag always has exactly one active redirect. But it can have multiple redirects in its history — so you can always go back to a previous destination.

The redirect engine

This is the heart of the system. Every scan goes through the following steps:

1. The QR code is scanned — the user visits a URL like qr.yourdomain.com/abc123

2. The engine looks up the tag based on the code

3. The engine retrieves the active redirect

4. The scan is recorded (asynchronously, so the redirect is not delayed)

5. The user is redirected to the destination

Step 4 is crucial. If you record the scan synchronously — before the redirect — you delay the user experience. At high volumes this can add up to hundreds of milliseconds. The solution is a queue: the scan is queued and processed asynchronously, while the user has already been redirected.

In Laravel this looks like:

dispatch(new TrackScan($tag, $request))->afterResponse();

return redirect($redirect->url);

The afterResponse() method ensures that the job is only queued after the response has already been sent. The user doesn't notice a thing.

Analytics

Every scan produces data. At minimum you want to track:

- Timestamp of the scan

- Device (mobile, desktop, tablet)

- Browser

- Country and city (via IP geolocation)

- Referrer (where does the user come from)

You aggregate this data per tag, per campaign and per time period. The dashboard shows charts, peak times and geographic distribution.

Scalability

A single redirect request is trivial. But suppose your system processes 100,000 scans per day — then scalability becomes a serious topic.

The bottlenecks are:

- Database queries for the redirect lookup

- Writing scan data to the database

- The queue worker processing scans

The solution for the redirect lookup is caching. A tag rarely changes — the redirect URL can easily be cached in Redis. With a cache hit, the lookup costs virtually nothing.

For scan data, batching is an option: collect scans in Redis and write them to the database in bulk every minute instead of one by one.

Multi-tenant

If you want to offer the system to multiple clients — each with their own tags, dashboards and users — you need a multi-tenant architecture.

The simplest approach is a tenant_id column on all relevant tables. Every query automatically filters on the active tenant. In Laravel you can solve this elegantly with a global scope.

Conclusion

A scalable dynamic QR system requires thoughtful architectural choices. The redirect engine must be fast, analytics asynchronous, the database optimized and the multi-tenant structure watertight.

I know this not from a tutorial. I built this system — it became dynatag.com. Now I build these kinds of systems custom for businesses through DynaTag.eu.

Need a dynamic QR system? Get in touch.

Tell me about your dynamic QR project. I'll give you honest advice within 24 hours — whether custom development is justified or not.