Processing 10k Concurrent RFID Payments at the Edge: Go, SQLite WAL, and EPC Gen 2

When engineering fintech and access control infrastructure for large-scale physical events, standard cloud architectures eventually hit a hard physical wall.

Under the Saudi Vision 2030 events strategy, mega-summits in Riyadh and Jeddah regularly process upwards of 10,000 delegates. At these scales, the operational realities of a crowded convention center break traditional web systems:

1. Saturated Networks: As thousands of delegates stream through the doors, local cellular macrocells congest and venue Wi-Fi suffers catastrophic packet loss.
2. Concurrency Bursts: 80% of gate traffic and 60% of food and beverage (F&B) purchases happen during narrow 30-to-45-minute windows (e.g., morning ingress and keynote breaks)[cite: 14].

If your event analytics platform or POS system relies on a synchronous HTTP handshake to a remote PostgreSQL database to open a turnstile or process a payment, it will fail under burst load.

To guarantee sub-second transaction times and zero gate downtime, we redesigned our RFID attendee tracking and cashless event payments architecture entirely around Edge Persistence and Dual-Frequency hardware.

Here is how we built it.

---

1. Dual-Frequency Credentials (UHF + HF)

The foundation of our architecture is a single physical smart credential (either a sub-3-second on-demand thermal badge or a durable silicone wristband).

We abandoned optical QR codes entirely. Instead, each credential contains a dual-frequency inlay with two distinct memory chips:

• Passive UHF EPC Gen 2 (865–868 MHz): Used strictly for zero-contact spatial tracking. Overhead RFID portals read these tags at distances up to 8 meters. Using dynamic Q-algorithm arbitration (Frame-Slotted ALOHA), a single portal can resolve up to 400 tag collisions per second, tracking venue capacity and sponsor dwell times without attendees ever breaking stride.
• Near-Field HF (13.56 MHz / NFC): Used for explicit intent actions, such as tapping to process a cashless payment at a vendor terminal or tapping to access a restricted ministerial VIP lounge.

---

2. Offline-First POS Architecture with SQLite WAL

If a vendor's Point-of-Sale terminal has to query an external cloud API to verify a wristband's wallet balance, the F&B queue will grind to a halt the moment venue Wi-Fi drops.

We pushed the financial ledger down to the edge. Each physical POS terminal and gate controller runs an embedded SQLite database in Write-Ahead Logging (WAL) mode[cite: 14].

sql
-- POS Edge Node Initialization
PRAGMA journal_mode = WAL;
PRAGMA synchronous = NORMAL;
PRAGMA busy_timeout = 5000;
PRAGMA temp_store = MEMORY;

-- Local Ledger Schema
CREATE TABLE IF NOT EXISTS edge_transactions (
    txn_id TEXT PRIMARY KEY,
    wallet_uid TEXT NOT NULL,
    vendor_id TEXT NOT NULL,
    amount INTEGER NOT NULL, -- Stored in base currency units (Halalas)
    epoch_ms INTEGER NOT NULL,
    sync_state INTEGER DEFAULT 0
);
Sub-Millisecond Tap-to-PayWhen a delegate taps their wristband to buy a coffee:The local NFC reader validates the cryptographically signed offline balance directly from the HF chip's secure memory sector.   

The transaction is appended to the local SQLite WAL companion file in under 4 milliseconds.   The physical UI updates instantly, completing the transaction.

A background Go daemon running on the terminal continuously monitors network health. When the internet connection is stable, it asynchronously flushes the committed transactions in batches to our central cloud API. If the internet drops, the terminal keeps selling.

3. Cloud Ingestion with Go & Redis StreamsTo handle the asynchronous telemetry bursts coming from hundreds of offline-resilient edge nodes, we use a Go-based ingestion layer backed by Redis Streams[cite: 14].Gopackage main

import (
    "context"
    "encoding/json"
    "net/http"
    "[github.com/redis/go-redis/v9](https://github.com/redis/go-redis/v9)"
)

var ctx = context.Background()
var rdb *redis.Client

type SyncBatch struct {
    Transactions []CashlessTxn `json:"transactions"`
}

func ingestEdgeBatch(w http.ResponseWriter, r *http.Request) {
    var batch SyncBatch
    if err := json.NewDecoder(r.Body).Decode(&batch); err != nil {
        http.Error(w, err.Error(), 400)
        return
    }

    pipe := rdb.Pipeline()
    for _, txn := range batch.Transactions {
        // Push to in-memory Redis Stream buffer
        pipe.XAdd(ctx, &redis.XAddArgs{
            Stream: "stream:cashless_ingestion",
            Values: map[string]interface{}{
                "txn_id": txn.TxnID,
                "wallet": txn.Wallet,
                "amount": txn.Amount,
                "vendor": txn.VendorID,
            },
        })
    }

    if _, err := pipe.Exec(ctx); err != nil {
        http.Error(w, "Ingestion Failed", 500)
        return
    }

    w.WriteHeader(http.StatusAccepted)
}
By pushing telemetry directly into an in-memory stream buffer, we completely decouple our primary PostgreSQL database from the extreme write contention caused by hardware synchronization bursts.4. Live Command via WebSocketsA worker pool consumes the Redis Streams, applies idempotent deduplication logic based on the txn_id, and computes rolling spatial and financial aggregations.

These metrics are then broadcasted via WebSockets directly to our KSA custom reporting dashboard. 

Event directors and financial controllers gain instant visibility into live vendor settlements, peak F&B purchasing windows, and civil defense hall capacities, all without aggressively polling the database.

ConclusionBuilding physical event technology requires acknowledging that venue networks will fail[cite: 1, 14]. By treating cloud connectivity as an eventual luxury rather than a strict requirement, we guarantee continuous ingress and revenue generation.

To explore how these architectures are deployed in the field across GCC exhibitions, review the hardware integration models behind StampIQ's cashless payments for events and their real-time event analytics platform.