Что такое микросервисы и какие преимущества они дают

Что проверяют

Не определение, а понимание последствий для питонового сервиса: как он запускается, как держит нагрузку, где начинается сетевой ввод-вывод, который раньше был вызовом функции. Спрашивают и бэкендеров, и тех, кто пришёл из скриптов и монолита на Django.

Как отвечать

Начните с сути: набор независимо разворачиваемых сервисов, каждый со своей бизнес-областью и своим хранилищем, общение через контракт.

Дальше говорите на языке Python. Процесс однопоточный по исполнению байткода, поэтому масштабирование идёт воркерами и репликами, и микросервисная нарезка помогает дать CPU-тяжёлому сервису отдельные ресурсы, не раздувая веб-слой. Контракт удобно описывать схемами и отдавать OpenAPI автоматически, чтобы потребители генерировали клиент, а не читали переписку.

# таймаут обязателен: без него зависший сосед держит воркеры
async with httpx.AsyncClient(timeout=httpx.Timeout(2.0)) as client:
    resp = await client.get(url)
    resp.raise_for_status()

Обязательно упомяните: своя база на сервис и свои миграции, общий код только в версионируемой библиотеке, а не в общей папке, фоновые задачи через брокер, обратная совместимость схемы при выкате, здоровье процесса отдельной ручкой для оркестратора.

Где спотыкаются

Оставляют одну базу на все сервисы и называют это микросервисами. Как только два сервиса пишут в одну таблицу, независимого релиза больше нет: миграция одного ломает второй, и откатывать приходится обоих.

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

Выносят в отдельный сервис то, что вызывается синхронно на каждый запрос и живёт в том же цикле изменений. Такой распил добавляет сериализацию и сеть, не добавляя независимости, и первым же нагрузочным тестом показывает деградацию.