← back to work
Case study · 2024

Fanverse

Fanverse enables fans from across the world to join in the real auctions and bid on the playing teams, the auction is designed in a way that engages you to be involved in the actual game way more than usual, because now you too is going to have a stake in it.

Role
Full-stack · Microservices
Timeline
4 months · 2025
Repository
GitHub ↗
Live
Visit site ↗
Next.jsExpressMongoDBGoRedisAWSREST
Fanverse complete user flow
Overview

When your tech has to match the hype

Fan engagement was the goal behind Fanverse. We needed a simulated environment where we can have hundreds and thousands of users join in and go through an enticing experience that would hype their involvement in the actual game way more than usual.

The first problem was that we cannot have this app as a passive dream team building system, rather we wanted the users to be engaged live in the game and have that sense of winning even before the game starts. Me being in the center of everything, started with a pretty naive approach of building the entire app as a server side rendered web app, meanwhile the real time auctions were handled in the same server instance over web sockets. It was quite early in our testing when we realized that the approach I have taken wouldn't be working on the real user load, since we were using server's memory to hold auctions' real-time data.

As the App had to move ahead from a mere MVP, I now took the system design of this app a step forward. The problem we faced with a stateful server with NodeJS gave us the challenges around the lines of Event Loop Blocking - when the bidding was done from 20 30 users and consequest database calls were being made, caused the bids being dropped, Race Conditions - inconsistent memory updates due to concurrent bids from multiple users on multiple auctions, Scalability - having multiple nodes of the server being load balanced would have caused a great gap in the states of the each node. Learning from the decisions we took previously, now pushed us to move our main auction service to GoLang and introduce Redis to hold states of multiple auctions.

By shifting our core auction engine to GoLang and decoupling the real-time state into Redis, we shifted our architecture into a highly scalable, stateless microservice. Go’s concurrency model — powered by lightweight goroutines—effortlessly handles thousands of simultaneous bidders without event loop blocking, while Redis serves as an ultra-fast data store that eliminates race conditions and automates memory cleanup via TTLs. This redesign completely resolved our data consistency and database choking, unlocking true horizontal scalability so Fanverse can confidently deliver a seamless, high-hype simulated auction experience to thousands of engaged fans.

<10ms
Real-time Bid Latency
10k+
simulated concurrent users
0%
bid drops
Walkthrough

Full project presentation

Open fullscreen ↗

Step through the deck with the arrows in the corners — no scrollbars, one slide at a time.

Next
See all projects →