Evrone

Large streaming services have one particular characteristic: you almost can't just "rewrite" them properly. While developers change the architecture, the product keeps living – people watch shows, streams go live, new releases come out, marketing runs special projects. Everything has to keep working simultaneously.

Our work with mоre tv and CTC's platforms wasn't a "we built a cool new service from scratch" story. It was about a rather painful transition from a heavy legacy system to an architecture that could be properly maintained going forward.

The project had a lot of what typically accumulates over the years at large media platforms: a Rails monolith, tightly coupled services, shared databases, a large number of integrations, and infrastructure that was already difficult to change without risking breaking something.

Projects like this always highlight the gap between "ideal" architecture and real-world development. In theory, everyone loves rewriting from scratch. In practice, you're more often carefully disassembling a functioning airplane mid-flight: https://evrone.com/cases/ctc-moretv

There is no single "right" framework in Go. And that's perfectly fine.

Some need a lightweight router with nothing extra. Others need a heavy MVC with ORM, authorization, and code generation. The choice depends not on trends but on the task: microservices, highload, monolith, MVP, or enterprise.

A Go framework doesn't make code "magically better." It just takes care of the routine: routing, JSON handling, validation, logging. That saves development hours and reduces the number of bugs. Plus, a new developer will get up to speed faster if the project uses a popular tool.

Next up – a quick overview of the most common options. What works for which task, how they differ, and where they might shine or just get in the way. A detailed breakdown is available in the article on our website: https://evrone.com/blog/best-golang-frameworks-2025

SberMegaMarket – 5 million products, 8 thousand sellers. At this scale, minor architectural flaws turn into real pain.

We joined as Go developers, mostly working on tasks for the SEO and advertising departments.

Reviews system.

We didn't just build a comment board – we built an engine with validation. A user writes a review, and the system checks: was it a real purchase? Is the content unique? Does it meet the "helpfulness" criteria? If yes – bonus rubles are credited. Everything is tied to Elasticsearch.

Photo gallery in reviews.

Previously, media was scattered. To see photos of a specific product, you had to dig through all the reviews. We aggregated everything into a single stream and created a unified access point.

Seller dashboard.

Vendors and brand representatives asked for the ability to respond to reviews – it didn't exist. We designed an account with this capability.

Advertising services.

Two of them: a campaign generator for Yandex.Direct and Google Ads, and an XML feed generator (products, prices, categories). Everything connects to external systems via API.

Brand aliases.

A brand can have a dozen spelling variations – Latin, Cyrillic, uppercase, lowercase. Previously, these sat statically in the database with no way to edit them. We built full CRUD – create, read, update, delete.

Stack.

Go (primary language), Elasticsearch (for reviews), Postgres, MS SQL, Redis, Vue.js, Gin, Go kit.

This isn't magic – just solid engineering. When the load is high, small things matter. We know how to handle that.

More technical details in the case study. 👉 Link in the post.

Migrating from Ruby to Go: pros, cons, and how to get it right

A Ruby project worked steadily for years, but now the load is growing, response time is increasing, and colleagues are advising a switch to Go.

Let's explore this with Alexander Kirillov, a DevOps expert and mentor in the Evrone DevOps internship program.

What Go offers. Compilation to machine code – high performance under load. Goroutines simplify parallel computing, unlike Ruby with its GIL. Static typing catches errors at compile time. The final binary includes all dependencies – no runtime environment or gem management needed.

The downsides. The Ruby ecosystem (Rails, Active Record, gems) is significantly richer. Many things in Go would have to be written from scratch. Strict rules: an unused variable will prevent compilation. No classes or inheritance – only structs and interfaces. Migrating a large project takes months, plus retraining the team.

How to decide. Assess the real problems. If performance is no longer satisfactory – Go might help. If everything runs smoothly, the switch may not be worth the effort. The best approach: rewrite one microservice in Go first, rather than starting a revolution.

Want to try Go but unsure? We can help with migration – from a test prototype to a full project rewrite.

More details in the article: https://evrone.ru/blog/articles/from-ruby-to-go

Viju is a streaming service. We designed its interface.
The main problem: users spend too much time choosing what to watch. They scroll, get tired, and leave. Not because the content is bad, but because the interface doesn't help.

Together with the product team, we decided to try an unconventional approach. Instead of standard genres – short looped video fragments of films, which we called "kinoms". In a couple of seconds, viewers grasp the atmosphere and decide whether they want to watch. No spoilers.

These fragments can be used to create playlists not by genre but by emotion. For example, "Autumn and rain outside the window". This makes it possible to connect films that are far apart in genre but fit a certain mood.

Before prototyping, we built functionality maps (mind maps) across three dimensions: the structure of sections, the UI/UX of those sections, and their information content. Then we created "gray" prototypes to test scenarios before starting design and development. This helped us drop complex or unimportant features early on.

We developed a unified design system: modular grids, typography, buttons, inputs, colors, dimensions. We took into account the specifics of each platform. For Smart TV – remote control navigation and its own guidelines. For mobile devices – differences across iOS and Android versions. For browsers – a separate mobile version, since that's where the main flow of advertising traffic comes from.

We tested with dozens of people who were already used to other streaming services. We implemented emotional tags, collected feedback, and prioritized the solutions.

If you need an interface that helps retain users instead of putting obstacles in their way – reach out. We'll tell you how we designed the design system for Viju and think about how we can help with your project.

More details on this case: https://evrone.com/cases/viasat-design

If you've worked with large Django projects, you probably know how quickly things can get hard to navigate.

How to get rid of the pain in large Django projects? Evrone developer Pavel Kutsenko decided to explore this and built next•dj.

Here's how he explains the problem and the solution:

"The real pain shows up on large projects – too many views, templates and handler functions scattered across different locations, and maintaining a 100k+ codebase becomes a nightmare. My project next•dj is built around file-routing architecture, where each block has its own URL prefix (on large projects, you sometimes have a microfrontend for different parts of the site). It includes static files (version 0.5.0 introduced the ability to store and process them right next to the page and component), form logic, templates, and context handler functions – what else do you need to be happy?"

Pavel started the experiment in the summer of 2025. In March of this year, versions 0.4.0 and 0.4.1 were released. The key update is the component system – a reusable UI block now lives in one place, with props, slots, and dependency injection. They also added a global NEXT_FRAMEWORK configuration, similar to DRF, keeping all settings in a single place.

The project is already on GitHub. It's a layer on top of Django that reflects this approach and might be useful if you've run into similar issues.

Come try it, fork it. More details on our website: https://evrone.com/blog/next-dj