Текущий рабочий проект - это 3commas.io. Высоконагруженое приложение с репликацией данных, огромным количеством джоб sidekiq и крутой командой разработчиков. Насколько я могу судить с перфомансом все достаточно неплохо, но есть проблемы в том, что очень много всего лежит в монолите, в связи с этим сейчас идет курс на то, чтобы немного распилить монолит и вынести из него в отдельные сервисы определенные части логики.
Я работаю в команде RND, делаем MVP всяких экспериментальных фич, типо новых торговых ботов, маркетплейса для приложений сторонних разработчиков.
К сожалению немного успел до конца курса сделать, но есть несколько кейсов, о которых можно расскзаать.
Использовал Scout, чтобы найти точки роста. В этой системе мониторинга очень удобно, что показывается N+1 проблемы.
Заметил, что на первом месте в API ендпоинт, в котором делается N+1 запросов в базу, а именно к ActiveStorage::Attachments.
Взял на себя устранить эту проблему, хотя наяпрмую к моей команде это не относилось. Сделал подгрузку картинок с помощью хелпера with_attached_smth и выкатили на прод.
В итоге ендпоинт пропал из раздела N+1 в Scout.
В процессе прохождения курса много узнал о разных системах монитринга, в том числе связка Prometheus + Grafana (они у нас всегда были в проекте, но я не знал как этим пользоваться). Заметил в процессе блуждания по графане странные пики нагрузки на пуму продакшена. Выяснил, что это за ендпоинт. Оказалось, что в этот ендпоинт наш же внутренний сервис делал вебхуки, причем делал их пиками до 15к в минуту. Посоветовавшись с коллегами, пришли к выводу, что такой флоу жил со времен, когда у нас еще не было Kafka, а сейчас как раз можно переделать взаимодействие на нее. Взялся за эту задачу (заодно это был мой первый опыт с работой с кафкой). Перевел флоу на Kafka, нагрузка на ендпоинт по понятным причинам свелась к 0.
Написал тесты для своего текущего рабочего проекта, чтобы избежать N+1 на всех ендпоинтах, где это возможно.
Необходимо было доставать информацию по примерно 150к аккантов из внешнего сервиса.
Использовал bulk_insert для записи в базу. Использовал функциональный индекс, для запросов, которые проверяют есть ли у нас уже такие сущности.
Потом по статистике в pg_hero понял, что этого все-таки недостаточно и немного переосмыслил код таким образом, что сократил запросы к базе(таблице с 80kk записей) в 13 раз. Для этого достаточно сначала сходить во внешний сервис, потому что у большинства аккаунтов там нечего получать и тогда уже и в базу идти не нужно, чтобы достать последнюю сущность которую мы выгрузили в прошлый раз(потому что ее там и не будет)
Пока это все, что могу расскзаать, но дальше больше! Буду стараться применять знания полученные в курсе на своем текущем месте работы!