Bukr

Event ticketing fails in two predictable ways. It oversells under burst load when everyone buys at once, and the fee model quietly erodes trust. Both are architecture problems, not bad luck.

A polyglot modular monolith. A Go and Fiber gateway owns auth, events, users and orchestration. A Rust and Axum core owns the correctness and throughput critical path: tickets, the gate scanner, payments and analytics. Supabase and Postgres for data and auth, Redis for cache and sessions.

Gateway and core talk over gRPC and HTTP and split by responsibility rather than fashion. Redis caches hot reads and holds sessions. Payment integration, an influencer and affiliate portal, credits, and a QR gate scanner round out the surface. A Vite and React SPA fronts it.

SELECT FOR UPDATE row locking inside transactions guards invite-token redemption, credit balances and influencer earnings, so two concurrent requests cannot double-redeem or oversell. The system uses heap-based ordering and per-route rate limiting, and the gateway-core split is itself a decision about where correctness must be strongest.

Go for the I/O-bound gateway where developer velocity and concurrency win, and Rust for the hot path where memory safety and raw throughput on ticket inventory and payments matter most.

A dual-language modular monolith that puts the language where it earns its keep, plus an influencer-driven distribution engine and a hybrid smart-pricing fee model designed against local market benchmarks.

A pan-African ticketing and event platform where reliability under a flash sale is the whole differentiator.