administration

Programmer's Blog: What Happens Under the Hood of gamer.ru

content auto translated from {from}

A Brief Historical Overview

The site gamer.ru has already undergone its third (and possibly even fourth) complete code rewrite. The project was originally written in Ruby-on-Rails back in the distant 2000s. The architecture was monolithic, so each user request "pulled" along a huge number of additional database queries and loaded all possible libraries. To ensure the resource could handle 100,000 visitors per day, it was necessary to deploy as many as five powerful servers, utilize memcache, Redis, and replicate databases across several servers. This allowed us to barely hold on until 2018, when the company began to experience financial problems, and the development team scattered.

Around 2020, the site lost its SSL certificate. Updating it turned out to be impossible because the old version of Ruby-on-Rails depended on an outdated version of OpenSSL, while new certificates required a more recent version. No one was particularly worried—the site continued to function, albeit poorly. From 2015 to 2025, traffic gradually fell from 100,000 to 1,000 visitors per day. In hidden blogs and comments, a huge amount of spam began to appear, including some rather inappropriate content. Yandex completely lost interest in us, and the webmaster console was filled with critical error messages.

What We Did to Fix Everything

The site needed serious optimization since the old architecture no longer matched the realities. About 100,000 posts and 1.6 million comments had accumulated in the database, which needed to be carefully migrated to the new engine. We decided to switch to a microservices architecture on both the backend and frontend, while employing modern technologies, including trendy HTMLElement's.

The project was completely rewritten from scratch in NodeJS without the use of third-party libraries, which guarantees us a peaceful existence for the next 10–20 years. Now we don’t have to worry that updating some trendy library like ExpressJS or React will break the entire site and require yet another massive refactor. Even the visual post editor had to be written from scratch, as we couldn’t find anything ready that would meet our modest requests. Now the engine renders HTML pages for old devices and search engines while delivering content to users via AJAX.

As of today, the site successfully handles an average load of about 150 requests per second, with a lion's share of traffic coming from search bots and other crawlers. Bots like Semrush and OpenAI behave particularly aggressively, acting as if they are trying to download the entire site in a day. While Yandex indexes us slowly, at a rate of 1-2 requests per second, these fellows can easily request up to 50.

However, the engine turned out to be so optimized that this entire bot army can be easily serviced by just one inexpensive virtual machine costing about 500 rubles per month.

Of course, the site periodically reminds us of itself with 502 and 504 errors, which are gradually identified and eliminated. Sometimes it turns out that someone forgot to add an index to the database, sometimes a complex query has to be broken down into several simpler ones, and sometimes there is simply no more space left on the server. But we don’t give up—the work continues, and the process, as they say, is "under control".

post more button

1081

post actions

Comments

Yeah, dynamic import is definitely a cool feature of JS.
I hadn't worked with such a stack before and I was used to a pretty strict separation between back-end and front-end, so a more flexible approach is not obvious to me.
I had encountered this more as a theoretical concept and had not seen such solutions in real projects. It was especially interesting to see this in action on a real website. Thank you!

Yes, something like that ) This approach also allows using modules with the same exports on both the front and back ends.

Like this:
let { session, ajax, addViewRoute } = typeof window !== 'undefined'
? await import("../../shared/frontend.js")
: await import("../../shared/backend-server.js")

This allows you to use the same code in both the browser and the server. It is especially useful for templates and defining public routes.

Cool! It somewhat reminds me of Dapr from .NET, a very interesting and elegant solution. Am I correct in understanding that the business logic does not know where the module is physically located, and the transport is chosen at the abstraction level? If so, it turns out a custom RPC abstraction has been implemented with switching between local calls and http?

a self-written gateway, made in such a way that microservices can either be part of a monolith or can be run as standalone microservices. That is, any API method can either remain within the monolith or be extracted separately with a couple of lines of code. This helps save memory (since it is limited, and one process requires about 200-500 MB of RAM), but at the same time, allows for distributing the load across additional servers. There is a universal function ajax(method, path,...), which calls functions from neighboring modules; if the neighboring module is in the same domain, the function is called directly, and if in another, it is done through a network request with the user's session identifier being passed through... Everything turned out very well, and, just to be safe, for now, everything is still hanging in the monolith.)

Thank you for the detailed analysis. It is especially valuable that not only the solutions are described, but also the real limitations that had to be faced. Such things usually remain behind the scenes.

I am curious, if it's not a secret, what are you currently using as an API Gateway? What has proven convenient for routing, auth, and rate-limit in a microservices architecture?

We simplified the mechanics a bit, and it was decided to update the engine as soon as possible, albeit with minimal functionality, since the old engine had a lot of bugs that got us banned from search engines, causing our traffic to drop to zero. The correspondence has been saved, the governance will appear a bit later, and we will further develop gamification elements. Energy and experience were transferred from the old database. We have not yet decided what to do with the medals and statuses, and we will try to implement the friends/subscriptions functionality in the near future.

The course towards the revival of Gamer, of course, cannot fail to please, but where, may I ask, have the remaining little bonuses from the old times gone: the VIP status that allowed editing posts without spending energy, the medals that brought such pleasant nostalgia, messaging with friends, and the overall friends list? Where is my stewardship on the blog "The Witcher 3: Wild Hunt"? And where is my personal Wiedzminka status, once earned by reaching level 60? Oh right, and where are the levels themselves? I am not asking for the light bulb back, but it is very disappointing to lose the elements of gamification that the old Gamer was famous for.

Thank you.