OneRP - 2,048 concurrent connections at MMORPG scale
The challenge
Classic roleplay platforms collapse under cumulative REST latency. The goal was a multi-tenant real-time platform where every screen updates from the authoritative server state.
What I built
OneRP is a long freelance mission around a private real-time platform. The core bet: remove HTTP request loops and use a binary, self-invalidating Fusion RPC channel so player, admin, banking, police and phone interfaces all refresh from the same server truth.
The same pattern now informs several SaaS architectures: reactive state, tenant isolation, compiler-enforced conventions and no manual cache invalidation.
Key engineering points
Fusion RPC over WebSocket with MessagePack for self-invalidating state.
Multi-tenant isolation enforced through InstanceId, EF Core query filters and middleware.
48 in-game React mini-apps tested in Chrome without launching the heavy game client.
Roslyn analyzers blocking real-time anti-patterns at build time.
Related writing
Why I removed REST APIs from my SaaS architectures
How reactive state with ActualLab Fusion changes user experience: no polling, no manual cache invalidation, no duplicated state.
OneRP - thousands of players where competitors cap around 500
Why I removed REST calls and designed server-side anti-cheat for a hostile, moddable runtime.
Similar technical risk?
I can help scope the risk, architecture and first deliverable.
A 30-minute first call is enough to see whether I am the right profile for the problem.
A similar challenge?
A system like this one to build? Let's talk.
I take on critical technical work — from scoping to production, no debt or lock-in once it's handed over. Fastest way to see if it fits: a 30-minute call.
I reply within 24h — often sooner.