When engineering the infrastructure for an event ticketing and management system in Saudi Arabia, the physical reality of the venue dictates the software architecture.
Under the Saudi Vision 2030 events strategy, mega-summits in Riyadh and Jeddah frequently process upwards of 10,000 delegates. These environments are hostile to standard cloud-dependent web applications:
- Network Saturation: Cellular towers congest and venue Wi-Fi degrades under massive attendee density.
- Fragmented Stacks: Venues traditionally run three isolated systems—one API for ticketing, a separate local database for gate turnstiles, and independent POS terminals for food/merchandise.
- High Concurrency Peaks: 80% of gate entries and 60% of F&B purchases happen in tight 30-to-45-minute windows (e.g., morning ingress and keynote breaks).
To eliminate venue queues and financial reconciliation errors, we built a unified, edge-resilient architecture that merges secure ticketing, RFID attendee tracking, and cashless event payments into a single cryptographic smart credential.
Here is how we architected the system to guarantee sub-second gate scans and offline-resilient financial transactions.
1. The Unified Credential: UHF RFID + NFC
Instead of relying on fragile optical QR codes that require line-of-sight scanning, the foundation of the system is a physical smart badge or RFID wristband.
When a delegate arrives, their digital ticket triggers an on-demand thermal print cycle (sub-3 seconds). Simultaneously, an integrated encoder writes an encrypted payload to a dual-frequency inlay:
- UHF EPC Gen 2 (865–868 MHz): Used for passive, zero-contact spatial tracking. Overhead portals read these tags at distances up to 8 meters to monitor civil defense hall capacities and VIP dwell times without requiring the user to stop.
- HF NFC (13.56 MHz / ISO 14443): Used for deliberate, secure intent actions—specifically, tapping to pay at a vendor terminal or tapping to open a restricted ministerial lounge door.
2. Edge-First Gate & POS Architecture (SQLite WAL)
If a vendor's Point-of-Sale (POS) terminal requires a round-trip HTTP request to a cloud server to verify a wristband's wallet balance, the transaction will inevitably fail when venue Wi-Fi drops.
To achieve guaranteed sub-second tap-to-pay transactions, we decoupled the physical read layer from the wide-area network. Both our gate controllers and vendor POS devices act as autonomous edge nodes.
Local Persistence with Write-Ahead Logging
Each edge terminal runs an embedded SQLite database configured for high-concurrency appends:
sql
-- POS Edge Node Initialization
PRAGMA journal_mode = WAL;
PRAGMA synchronous = NORMAL;
PRAGMA busy_timeout = 5000;
PRAGMA temp_store = MEMORY;
CREATE TABLE IF NOT EXISTS local_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
);
When an attendee taps their wristband to purchase a coffee, the NFC reader validates the cryptographically signed wallet balance directly from the chip's secure memory sector.
The ledger deduction is written to the local SQLite WAL companion file in under 4 milliseconds.
A background Go daemon continuously monitors network health and asynchronously flushes committed transactions to the central cloud API when connectivity permits.
3. High-Throughput Ingestion Pipeline (Go & Redis)When network connectivity is stable, hundreds of edge portals and POS terminals continuously stream telemetry and financial ledgers to the central cloud.
To prevent our primary PostgreSQL relational database from locking under heavy concurrent writes, we use Redis Streams as a high-speed ingestion buffer. Our Go ingestion gateway handles incoming TCP payloads and pushes them to Redis in memory:Gopackage main
import (
"context"
"encoding/json"
"log"
"net/http"
"[github.com/redis/go-redis/v9](https://github.com/redis/go-redis/v9)"
)
var ctx = context.Background()
var rdb *redis.Client
type CashlessTxn struct {
TxnID string `json:"txn_id"`
Wallet string `json:"wallet"`
Amount int `json:"amount"` // Halalas
VendorID string `json:"vendor_id"`
EpochMS int64 `json:"epoch"`
}
func ingestTransaction(w http.ResponseWriter, r *http.Request) {
var txn CashlessTxn
if err := json.NewDecoder(r.Body).Decode(&txn); err != nil {
http.Error(w, err.Error(), http.StatusBadRequest)
return
}
// Push to in-memory Redis Stream buffer
err := rdb.XAdd(ctx, &redis.XAddArgs{
Stream: "stream:cashless_transactions",
Values: map[string]interface{}{
"txn_id": txn.TxnID,
"wallet": txn.Wallet,
"amount": txn.Amount,
"vendor": txn.VendorID,
"epoch": txn.EpochMS,
},
}).Err()
if err != nil {
http.Error(w, "Ingestion Failed", http.StatusInternalServerError)
return
}
w.WriteHeader(http.StatusAccepted)
}
4. Live Financial & Spatial Command DashboardsA worker pool consumes the Redis Streams, applying deduplication (based on TxnID) and writing the settled records to TimescaleDB for permanent storage.
Simultaneously, the workers compute rolling 60-second aggregations and broadcast them via WebSockets to our KSA custom reporting dashboards.
This provides event operations teams with real-time, actionable intelligence:Live Vendor Settlements: Financial controllers can monitor live POS revenue across the entire exhibition floor, tracking exact spending velocity without waiting for end-of-day batch processing.
Civil Defense Density Adherence: Security teams receive immediate alerts if passive UHF portals detect that a specific keynote hall is nearing its municipal capacity limit.
Architecting for Scale in the GCCBy unifying ticketing, spatial tracking, and digital wallets into a single edge-resilient architecture, we eliminate the physical queues and data silos that plague legacy event operations.
If you are developing solutions for physical venues or exploring hardware-integrated fintech, review the deployment models powering StampIQ's cashless payments for events and their enterprise event registration platform
Top comments (0)