Перенесла повільну роботу зі шляху запиту в чергу завдань River — 15 модулів воркерів, 8 запланованих задач та 20 завдань pg_cron — щоб запит повертався, поки робота за ним триває.

Ситуація. Частині роботи взагалі нема чого відбуватися, поки користувач чекає. Надіслати лист, перебудувати пошуковий індекс, згенерувати документ, перерахувати рейтинги — якщо робити будь‑що з цього всередині запиту, користувач дивиться на спінер через те, чого він ніколи й не просив бачити. А якщо винести це в горутину, робота зникне тієї ж миті, коли процес перезапуститься, — а він перезапуститься, посеред розгортання, і не лишиться жодного сліду, що вона взагалі мала відбутися.

Завдання. Фоновій роботі потрібне було надійне місце: черга, яка переживає перезапуск, повторює невдалі спроби і в яку можна зазирнути, коли щось не відбулося.

Дія. Вибір упав на River — переважно тому, що він тримає свою чергу в PostgreSQL: база даних і так є головним джерелом істини, тож завдання і рядки, які воно змінює, комітяться або відкочуються разом, і не треба запускати й тримати в голові ще один компонент інфраструктури. За ним стоять 15 модулів‑воркерів і 8 запланованих завдань. Рівнем нижче 20 завдань pg_cron виконують обслуговування, яке базі даних краще робити самій: чистять старі партиції, ротують солі, оновлюють агрегати. Усе, що працювало помітно повільно, винесено зі шляху запиту в один із цих двох механізмів.

Результат. Запити виконуються швидко, а повільна робота все одно доходить до кінця, а коли ні — є повторні спроби й видима історія. Тримати чергу в Postgres, а не в окремому брокері, — свідоме обмеження: таке рішення не масштабуватиметься нескінченно, і за певного обсягу стане хибним. Для платформи, вузьке місце якої і так база даних, мінус одна рухома частина важила більше, ніж запас потужності, яким однаково ніхто б не скористався.