Ratingo: чому ми переписали все з нуля
Ratingo починався дуже просто.
Я навайбкодив MVP на Next.js, де фронтенд і бекенд були фактично одним цілим. Це був швидкий експеримент — перевірити, чи взагалі ідея сервісу, який підказує, що подивитись, цікава комусь ще, окрім мене. Бо на старті Ratingo був суто особистим проєктом: я робив його для себе, він працював тільки локально і не замислювався як щось публічне
І, як виявилось — потрібна.
Про Ratingo написали українські техно-медіа: ITC, dev.ua та ще кілька інших. Після публікацій на сайт почали заходити люди — не десятки, а тисячі гостей одночасно, щоб подивитися, що це за сервіс.
І тут сталося те, що мало статися 🙂
Проєкт із самого початку будувався як локальний. Він крутився на k3s-кластері з 4 Raspberry Pi, які чесно тягнули бек, фронт і “будували повістку дня”: які серіали зараз варто дивитися, що виходить, що в тренді.
Але після публікацій усе просто… лягло.
По-перше, залізо не витягнуло. Довелося терміново переїжджати в хмару — на Railway.
По-друге (і це було болючіше), я дуже чітко побачив, наскільки погано був написаний бекенд.
Деякі запити відповідали по кілька секунд, логіка була розмазана між клієнтом і сервером, масштабування — майже нереальне.
Паралельно почали приходити люди з ідеями, фідбеком і покращеннями.
І один із найчастіших запитів був простий і логічний:
А буде мобільний додаток?
І саме в цей момент стало очевидно:
Ratingo треба переписувати з нуля.
Що я зробив
У якийсь момент я зрозумів, що проблема не лише в архітектурі клієнтів і бекенду. Вона була глибша: у Ratingo не існувало єдиного місця, де були б зібрані й послідовно застосовані всі правила роботи з контентом.
Тому я заклав в основу системи policy engine — окреме ядро правил. Він не “вирішує”, що користувачу дивитись, а визначає умови й обмеження, за якими контент потрапляє в продукт і в якому вигляді.
Простою мовою, policy engine відповідає на питання:
що вважати релевантним контентом у конкретному контексті,
що відфільтрувати як шум або тимчасовий хайп,
які дані можна показувати новому користувачу,
як по-різному поводитись із серіалами, що щойно вийшли, і з тими, що давно завершені.
Важливо, що ці правила не захардкоджені у клієнтах і не розкидані по сервісах. Вони зібрані в одному місці, застосовуються однаково для всіх сценаріїв і можуть змінюватися чи розширюватися без переписування фронтенду.
Фактично, policy engine став єдиною точкою входу до даних у Ratingo.
Саме цей підхід дозволив Ratingo еволюціонувати від “сайту з каталогом” до системи з чіткими правилами, яка масштабується разом з продуктом і аудиторією.
Окремим великим шматком я переосмислив систему рейтингу. Бо дуже швидко стало зрозуміло: просто показувати IMDb або TMDB — цього недостатньо.
У Ratingo рейтинг — це не одне число, а результат формули, яка враховує кілька незалежних факторів.
По-перше, ми агрегуємо зовнішні рейтинги з різних джерел. Але не просто усереднюємо їх. Кожне джерело має свою “вагу”, а сам рейтинг коригується залежно від кількості голосів. Оцінка 9.0 з десяти голосів і 8.2 з десяти тисяч — це зовсім різні сигнали, і система це враховує.
По-друге, ми дивимось на рівень довіри до рейтингу. Якщо контент новий і голосів ще мало — рейтинг не вважається стабільним і не отримує максимального впливу на фінальний бал. Це дозволяє не переоцінювати гучні новинки в перші дні після релізу.
По-третє, у формулі є популярність і динаміка інтересу: скільки людей додають контент у списки, як швидко росте увага, чи це короткий хайп, чи стабільний інтерес у часі. Це не “якість”, але важливий контекст.
У результаті фінальний рейтинг — це не просто “наскільки добре”, а відповідь на складніше питання:
наскільки цьому контенту можна довіряти прямо зараз і кому він може підійти.
Саме тому Ratingo може показувати не лише число, а й контекст:
чому цей серіал зараз у топі, чому інший має високу оцінку, але не рекомендується всім, і чому деякі речі краще “відкласти на потім”.
Нова модель фонових процесів у Ratingo
Окремо я переосмислив й те, як у Ratingo виконуються фонові задачі.
У першій версії все було максимально прямолінійно: звичайні cron-джоби за розкладом стукались у ендпоінти. Але тепер запуск по часу — це лише сигнал, а не сама робота. Задача потрапляє в чергу, отримує свій контекст і правила виконання, а далі система чітко знає, коли вона стартувала, як відпрацювала і чим завершилась.
Це важливо для всього, що відбувається в Ratingo регулярно: оновлення рейтингів і трендів, синхронізація з зовнішніми джерелами, перерахунок політик і підготовка вітрин для клієнтів. Усі ці процеси тепер працюють передбачувано й масштабуються.
Що далі
Ratingo більше не MVP “на коліні”. І так — робота над ним ще триває. Це не фінальний продукт, але це вже інший рівень.
Дякую всім, хто прийшов, провів навантаження, залишив фідбек і змусив зробити Ratingo кращим ❤️