Python мок-интервью: rate limiting, Redis и конкурентность
Живое мок-собеседование для Python-бэкендера: кандидат проектирует rate limiter, разбирает GIL и конкурентность, затем обсуждает архитектуру асинхронного сервиса транскрибации видео, очереди, Celery и масштабирование.
В живом мок-собеседовании кандидат с примерно 2,5 годами опыта отвечает на вопросы о rate limiting: Fixed Window, Token Bucket и Leaky Bucket, идентификации анонимных клиентов при CGNAT, Redis и атомарности. Затем обсуждаются middleware и декораторы Django, GIL, потоки, процессы, asyncio и примитивы синхронизации. Во второй задаче участники проектируют асинхронный сервис транскрибации загружаемого видео: S3, FFmpeg, Celery, брокеры, гарантии доставки, Transactional Outbox, ретраи, восстановление долгих задач, масштабирование и наблюдаемость. В финальной обратной связи интервьюер характеризует этот набор вопросов как уровень Middle+ и выделяет у кандидата точки роста в системном дизайне и проработке неструктурированных задач.
Алгоритм rate limiting выбирают по ожидаемым всплескам нагрузки и допустимому характеру ограничения.
IP-адрес не всегда идентифицирует одного пользователя из-за CGNAT, прокси и анонимных клиентов.
Для многошаговой логики rate limiting в Redis счётчик и срок жизни ключа нужно обновлять как единое действие, например Lua-скриптом. Раздельные INCR и EXPIRE могут нарушить инвариант.
В CPython GIL не делает составные операции над общим состоянием безопасными. Для CPU-bound вычислений обычно используют процессы, а I/O-bound нагрузка может выигрывать от потоков или asyncio.
Многоэтапную обработку стоит делить на независимые задачи, хранить промежуточное состояние вне воркера и ретраить только упавший этап.