administration

Blog do Programador: o que acontece por trás do gamer.ru

content auto translated from {from}

Um breve histórico

O site gamer.ru passou por uma terceira (e talvez até uma quarta) reescrita completa de código. O projeto foi inicialmente escrito em Ruby-on-Rails ainda nos longínquos anos 2000. A arquitetura era monolítica, então cada solicitação do usuário "puxava" uma enorme quantidade de solicitações adicionais ao banco de dados e carregava todas as bibliotecas possíveis. Para garantir o funcionamento do recurso com 100 mil visitantes por dia, foi necessário envolver cinco servidores potentes, usar memcache, Redis e replicar bancos de dados em vários servidores. Isso permitiu, de alguma forma, sobreviver até 2018, quando a empresa começou a enfrentar problemas financeiros e a equipe de desenvolvedores se dispersou.

Cerca de 2020, o site perdeu o certificado SSL. Atualizá-lo se mostrou impossível, pois a versão antiga do Ruby-on-Rails dependia de uma versão antiga do openssl, enquanto os novos certificados exigiam uma versão mais recente. Ninguém se preocupou muito — o site continuou a funcionar, mesmo que mal. Entre 2015 e 2025, o tráfego caiu gradualmente de 100 mil para mil visitantes por dia. Nos blogs e comentários ocultos, começou a aparecer uma enorme quantidade de spam, incluindo conteúdo não muito apropriado. O Yandex perdeu completamente o interesse por nós, e no webmaster havia um painel vermelho cheio de erros críticos.

O que fizemos para corrigir tudo

O site precisava de uma otimização séria, pois a antiga arquitetura já não correspondia à realidade. No banco de dados, havia acumulado cerca de 100 mil posts e 1,6 milhões de comentários, que precisavam ser cuidadosamente transferidos para um novo motor. Decidimos mudar para uma arquitetura de microsserviços tanto no backend quanto no frontend, aproveitando tecnologias modernas, incluindo os modernos HTMLElement's.

O projeto foi completamente reescrito do zero em NodeJS sem o uso de bibliotecas de terceiros, o que nos garante uma vida tranquila nos próximos 10 a 20 anos. Agora, não precisamos temer que a atualização de alguma biblioteca moderna como ExpressJS ou React quebre todo o site e exija uma nova reestruturação em grande escala. Até mesmo o editor visual de posts precisou ser escrito por nós mesmos, já que não encontramos nada pronto que atendesse às nossas modestas demandas. Agora, o motor renderiza páginas HTML para dispositivos antigos e mecanismos de busca, enquanto entrega o conteúdo para os usuários via AJAX.

Hoje, o site suporta com sucesso uma carga média de aproximadamente 150 solicitações por segundo, sendo que a maioria do tráfego é composta por bots de pesquisa e outros crawlers. Especialmente ativos são os bots semrush e openai, que se comportam como se tentassem baixar todo o site em um dia. Se o Yandex nos indexa lentamente, a uma taxa de 1-2 solicitações por segundo, esses sujeitos podem solicitar até 50.

No entanto, o motor foi tão otimizado que todo esse exército de bots é facilmente atendido por uma única máquina virtual barata, custando cerca de 500 rublos por mês.

Claro, periodicamente o site nos lembra de sua presença com erros 502 e 504, que estão sendo progressivamente identificados e corrigidos. Às vezes, descobre-se que alguém esqueceu de adicionar um índice ao banco de dados, outras vezes uma consulta muito complexa precisa ser dividida em várias simples, ou até mesmo falta espaço no servidor. Mas não desistimos — o trabalho continua, e o processo, como dizem, está "sob controle".

post more button

1081

post actions

Comentários

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.