Shipping a 56,000-game portal as a one-person operation: the stack that holds it together

Running a website with 56,000 games might sound like a team effort, but in our case, it's mostly just one person, a budget server, and a stack focused on reliability rather than cleverness. This story reveals the key components that keep GameZiko running, along with the important decisions that matter most.

First and foremost, the game pages are mostly static HTML generated at build time. With over 56,000 dynamic page renders per deployment, rendering all that content dynamically would have been impossible. So, the catalog is pre-rendered, including all the essential details like title, description, tags, embed information, and related games.

The dynamic parts, such as search and recently played, are handled by small API calls against a lean index. The rule of thumb is simple: if it doesn't change per user, it shouldn't be computed per request.

The game files themselves are self-contained HTML5 bundles, which makes things easier. However, the real challenge lies in ensuring metadata quality. Incorrect titles, broken thumbnails, or incorrectly categorized tags can render a game page useless. To tackle this issue, we built a pipeline that validates each submission: it checks if the game loads in a sandbox, responds to user input correctly, and verifies that the thumbnail has the right aspect ratio.

About a third of submissions fail this validation and never make it to the site. This validation process is crucial and essentially forms the backbone of our product.

When it comes to search functionality, we opted for a simple, humble solution. Instead of running a resource-intensive index like Elasticsearch, we use a precomputed trigram index combined with tag weighting to handle searches effectively. Accepting that your search doesn't need to be as sophisticated as Google can save a significant amount of infrastructure costs.

Images pose a silent budget killer, particularly with 56,000 thumbnails to manage. To keep costs in check, we aggressively compress our WebP thumbnails at fixed dimensions and serve them from a CDN with long cache headers. Each page's weight remains under 300KB, excluding the actual game file. Given that most visitors access the site using phones or school Chromebooks, this discipline is crucial for maintaining a playable experience.

Caching is a key strategy throughout the site. Since game pages rarely change, cache time-to-live (TTL) values are measured in days, not minutes. The only events that invalidate the cache are metadata corrections, which are handled through targeted purges. The stale-while-revalidate strategy ensures optimal performance.

In terms of infrastructure, most of the server's workload consists of serving API requests and handling the build pipeline. The CDN takes care of the heavy lifting, effectively performing most of the work. For a solo developer, it's essential to monitor critical aspects of the system. Our monitoring setup is straightforward, consisting of three alerts: error rate spikes, deploy failures, and disk space issues.

We rely on weekly report emails for additional insights. Keeping monitoring simple and focused on essential metrics is more effective than an overly complex system that gets ignored.

Looking back, I would have prioritized building the validation pipeline first, rather than adding it as an afterthought. Cleaning up ten thousand bad entries was the most challenging and frustrating month during the project. If you're responsible for managing a user-submitted catalog, investing time in validation at the point of entry can save you significant headaches and costs in the long run.

In summary, GameZiko's success hinges on pre-rendering static content, validating metadata at the source, compressing images aggressively, and keeping the dynamic surface minimal. By following these principles, GameZiko maintains fast performance despite operating on a tight budget. This architecture refuses to perform unnecessary work, allowing the site to stay fast and efficient.