Как изучали архитектуру онлайн кинотеатра?
Что проверяют
Это вопрос о вашем проекте, а не о чужих сервисах. Интервьюер хочет понять, разбирались ли вы, почему система устроена именно так, или собрали её по инструкции. Следом обычно просят нарисовать схему и сказать, что сломается первым при росте нагрузки.
Как отвечать
Стройте ответ вокруг своего проекта: какие сервисы были, за что отвечали вы, какие решения принимали сами. Типичный набор для онлайн-кинотеатра на Python:
- админка: Django и PostgreSQL, редакторы заводят фильмы, жанры, персон;
- поиск: ETL переносит данные из PostgreSQL в Elasticsearch, потому что поиск с опечатками и фасетами в реляционной базе обходится дороже;
- API каталога: асинхронный FastAPI, ответы кэшируются в Redis;
- авторизация: отдельный сервис, короткий access-токен (JWT), refresh-токен с возможностью отзыва, роли;
- пользовательские события: просмотры и закладки идут через Kafka в аналитическое хранилище вроде ClickHouse и не нагружают основную базу;
- видео: файлы лежат в объектном хранилище, заранее перекодируются через
ffmpegв HLS или DASH с несколькими битрейтами и отдаются через CDN. Python-приложение видеопоток не раздаёт.
Затем расскажите, как именно изучали: читали документацию, рисовали диаграммы, гоняли нагрузку через locust, искали узкое место. Нужны свои цифры: сколько RPS держал API, как изменилось время ответа после кэша. Если проект учебный, так и скажите. Учебный проект, где вы сами спроектировали сервис авторизации, звучит сильнее выдуманной продакшн-нагрузки.
Где спотыкаются
Перечисляют технологии без причин. На вопрос «зачем Elasticsearch, если в PostgreSQL есть полнотекстовый поиск» ответа нет, и весь рассказ обесценивается.
Говорят «прототип показал высокую производительность» без чисел и методики. Интервьюер сразу спросит, какая была нагрузка, чем мерили и на каком железе.
Предлагают отдавать видео через Django или FastAPI. Стриминг держится на сегментах, объектном хранилище и CDN, иначе один популярный фильм кладёт весь бэкенд.