Сразу хотелось бы отметить, что все вопросы, связанные с поставленным ТЗ, на работе я бы сразу уточнил необходимую мне информацию у человека отвественного за это ТЗ. Как говорится, семь раз отмерь - один раз отрежь.

Так как задание начал делать очень поздно, шанса на ошибку в проектировании и продумывании решении проекта у меня не было, поэтому много времени уделил выбору стека технологий для решения поставленной задачи.

В поставленном ТЗ, на мой взгляд, были некоторые противоречия, к примеру:

• Фича и тег однозначно определяют баннер, но баннер может иметь одну фичу и несколько тегов. Что это может значить? Предположим, что множество тегов одного баннера не пересекается со множеством тегов другого. Тогда утверждение, что "фича и тег" однозначно определяют баннер" имеет смысл. С другой стороны, если обратится к представленному файлу api и внимательно его прочитать, то при обращении get user_banner передается только один тег. Что опять же намекает нам на непересекающиеся множества тегов. НО! В условии сказано: "При этом один тег, как и одна фича, могут принадлежать разным баннерам одновременно", то есть имеется некоторое противоречие. К тому же, с логической точки зрения, тег и должен быть неуникальным, к примеру: тег "спорт" или тег "программирование". Логично представить, что эти теги могут принадлежать разным банерам. Поэтому подытожу, что я решил при решении: "фича и теги однозначно определяют баннер".
• Так как не успел доделать, хотелось бы упомянуть, что для решения условия, связанного с use_last_revision, нужно использовать допольнительное БД, к примеру Redis. Возможно допишу уже после дедлайна
• Для решения задачи, нужно было очень правильно подойти к вопросу проектирования БД и придерживатся хороших практик. К примеру, вместо вписывания в таблицу banner поле feature_id, нужно создать отдельное БД feature и связать БД, отдельной таблицей banner_feature. При этом не нарушаются основы построения БД.
• По поводу авторизации и аутентификации я думаю должен существовать другой сервис, в котором должна проходить регистрация пользователя, а также настройка админских прав. Так как не успел дописать, напишу, что возможным вариантом, можно было использовать сервис единого входа SSO. У меня есть такой сервис, вот он, там был выбран поход RBAC.
• Последнее что хотелось бы отметить, что задание довольно таки хорошее, оно подтолкнуло меня узнать новые вещи о разработке, его было интересно решать, так как условие было написано близко к производственному. Хоть все задания тестового задания в дедлайн я не решил, точно допишу все задания после для прокачки навыков. Также хотелось бы увидеть эталонное решение от крутых Авито разработчиков

make up   //миграции up
make down //миграции down
make run  //запуск приложения