DEV Community

stampiq
stampiq

Posted on

Building an Offline-First Architecture for 40,000+ Concurrent RFID Scans


If you build consumer web apps, a 2-second API latency is an annoyance. If you build infrastructure for mega-events and music festivals, a 2-second API latency at the front gate causes a dangerous crowd crush.

Over the last few years, the scale of outdoor events across the Middle East has exploded. We routinely see 40,000+ attendees descending on remote desert venues simultaneously. When that happens, the local cell towers completely overload and die.

If your gate scanners rely on a continuous cloud connection to verify a QR code, your system will freeze. The line stops moving, and your event operations fail before the first act even hits the stage.

Here is how modern event tech architects are solving this by shifting from cloud-dependency to edge computing.

The Flaw in Cloud-Dependent Ticketing

Standard registration apps scan a barcode and ping a centralized AWS or GCP database.
Scanner -> Cellular Network -> Cloud DB -> Response (Valid/Invalid) -> Scanner

When the cellular network bottlenecks, that request times out.

To solve this, the top smart event platforms Saudi Arabia have moved entirely to offline-first hardware ecosystems utilizing passive RFID chips.

Edge Nodes and Local Caches

Instead of relying on the cloud, we treat every single turnstile scanner as an independent edge node.
Every morning, the master registration database is downloaded to the scanner's local storage (typically a SQLite instance).

When an attendee taps their fabric wristband against the reader, the scanner is not looking for Wi-Fi. It queries the local SQLite cache.

  1. Read encrypted UID from the chip.
  2. Query local DB: SELECT status FROM attendees WHERE uid = ?
  3. Flash Green/Red and actuate the turnstile.

This localized architecture processes attendees in 0.8 seconds per tap, completely immune to internet outages.

Asynchronous Data Syncing

While the hardware operates offline, the data still needs to reach the command center. We utilize asynchronous background workers on the scanners. The moment the hardware detects even a sliver of bandwidth, it batches the scan logs and pushes them to the cloud via a message broker (like RabbitMQ or Kafka).

This ensures that the command center can still utilize continuous rfid delegate tracking without the primary access gates ever relying on a live connection.

If you are building tech for large-scale physical operations, you cannot trust the internet. Build for the edge, cache locally, and sync asynchronously.

Top comments (0)