Вам нужно провести исследование по выбору хранилища. Предлагаем идти по этому чек-листу:

Выбрать хранилище для задачи.
Написать скрипт, который генерирует в хранилище данные.
Измерить скорость добавления и чтения данных:
Тестирование чтения уже загруженных данных. Тестирование нужно проводить на реальных кейсах (2–3 из набора):
список понравившихся пользователю фильмов (список лайков пользователя);
количество лайков или дизлайков у определённого фильма;
список закладок;
средняя пользовательская оценка фильма.
Тестирование чтения данных, поступающих в реальном времени:
добавление лайка или дизлайка и время появления лайка или дизлайка в сценариях, описанных выше.
Выбрать и описать причины выбора:
разработать отдельный сервис;
добавить в уже существующий сервис.

Итоги

В результате вашего исследования должны появиться чёткие ответы и понятия:
Хранилище с описанием причин его выбора. Опишите ваш вариант хранения данных.
Результаты тестирования скорости работы с хранилищем в формате .md файла (README.md).
Файлы для воспроизведения исследования:
docker-compose.yml для запуска кластера с хранилищем;
конфигурационные файлы для хранилища (если такие есть);
скрипт генерации данных в хранилище;
скрипт тестирования чтения данных из хранилища;
README.md, в котором описано, как запустить хранилище и скрипты.
Описание реализации сервиса:
разработка отдельного сервиса (Почему именно так? Какие могут быть проблемы?);
добавление в уже существующий сервис (Почему именно так? Какие могут быть проблемы?).
Все результаты исследования оформите для ревью и отправьте вашему ментору по выбору хранилища.

Подсказка 1

Для этой задачи скорость записи не так важна, как скорость чтения. Скорость чтения должна быть главным критерием выбора хранилища.

Подсказка 2

При выборе хранилища учитывайте его сильные и слабые стороны, а также движок базы данных. Например, запись в LSM-Tree происходит быстрее, чем чтение, но LSM-Tree всё же используется в некоторых БД.

Написать отдельный сервис(доработать существующий)

Исправить проверку линтерами.
flake8 желательно заменить на wemake-python-styleguide
Сделать вывод в красивый html-файл. В настройках линтеров есть такая опция.
Добавить проверку типов с помощью mypy.
Сделать проверку работоспособности кода на версиях python 3.7, 3.8 и 3.9. В этом поможет использование strategy.
Добавить отправку сообщения об успешности прохождения CI в телеграм.
Сделать срабатывание CI-процесса на новые pull request в master-ветку.
Исправить все недочёты, найденные линтерами и статическими анализаторами.

Привет! Молодцы! Ниже несколько рекомендаций:

1. Давайте сделаем так, чтобы sentry можно было отключать через конфиг, например, в тестах
2. Прочитайте более внимательно для чего нужен этот параметр: https://docs.sentry.io/platforms/python/performance/#configure-the-sample-rate. Это рейт не по ошибкам, а по транзакциям, по факту это что-то вроде мониторинга, но есть проблема, что sentry в это не особо умеет (умирает под не очень большой нагрузкой), рекомендую не выставлять этот параметр или явно прописывать 0
3. Не понял зачем вы здесь код дублируете
4. Не рекомендую под main писать такой объем кода, давайте вынесем его в функцию и немного декомпозируем

Настройте Sentry и наладьте в отправку json-логов в ELK для всех сервисов.
Перед сдачей кода на ревью убедитесь:
что вы можете просмотреть логи каждого приложения;
в логах корректно указан X-Request-Id;
информация разделена по уровням важности;
по записям в логах можно воссоздать происходившее в сервисах;
в логах нет приватной информации;
логи собираются из файла или с stdout.