Tevian: Python senior, backend performance и системные расчеты

Сначала фиксируем симптом и SLO, затем смотрим метрики/логи/traces, локализуем слой: API, serialization, DB, queue, network или CPU. После этого воспроизводим локально и проверяем гипотезу измерением.

Хороший ответ начинается не с "переписать на Go", а с вопроса: какой именно SLO нарушен и где это видно. Нужно посмотреть latency, error rate, throughput, saturation, очереди, пул соединений и ресурсы процесса. Дальше раскладываем путь запроса: API handler, serialization, внешние сервисы, база, очередь, CPU-bound код.

Если подозрение на базу, надо смотреть slow query log, EXPLAIN/EXPLAIN ANALYZE, индексы, selectivity, connection pool и объем результата. Если CPU-bound код, пригодятся профилировщик и проверка горячих функций. Если проблема в долгой фоновой задаче, можно выделить producer/consumer, batch size, backpressure и шардирование работы.

Важно закрывать цикл измерением: было N секунд, стало M секунд, не сломали correctness и не ухудшили другие метрики.

На review стоит назначать минимум эксперта по домену и человека, который погружается в проект. Первый отвечает за correctness, второй расширяет bus factor.

Практичная схема: каждый MR смотрит maintainer или domain owner, который понимает бизнес-логику и архитектурные границы сервиса. Второй reviewer может быть разработчиком, которого нужно погрузить в эту часть кодовой базы. Так review становится не только gatekeeping, но и системным onboarding.

На review нужно проверять не только style. Важнее семантика изменения, границы слоев, тесты, миграции, обратная совместимость API, observability и влияние на performance. Мелкие style-вопросы лучше автоматизировать formatter/linter-ом, чтобы люди тратили внимание на design и correctness.

Хорошая политика также ограничивает количество итераций: понятные checklist-и, маленькие MR, owners по подсистемам и быстрый feedback loop.

Status 200 проверяет только оболочку. Полезный тест должен проверять бизнес-эффект: запись в БД, вызов зависимости, side effects, ошибки, права и важные edge cases.

Тест "endpoint вернул 200" часто почти ничего не доказывает. Нужно понять контракт фичи: что должно измениться в системе и какие инварианты должны сохраниться. Для create/update endpoint это может быть запись в БД, корректные поля, транзакционность, публикация события, idempotency и обработка невалидного input.

В backend обычно нужна пирамида: unit-тесты для чистой логики, integration-тесты с БД/очередью для важных сценариев, contract-тесты для внешних API и producer/consumer схем. Регресс должен ловиться до ручной передачи QA.

На review стоит просить тесты, которые падают при реальной поломке бизнес-сценария, а не просто выполняют happy path без assert-ов.

Нужно явно описывать API/event schemas, версионировать изменения и гонять contract tests между producer и consumer версиями. Breaking changes должны идти через migration window.

Для HTTP API контракт можно фиксировать через OpenAPI/JSON Schema/gRPC proto, для событий - через schema registry или явно версионированные event schemas. Важно не давать сервисам читать чужие таблицы напрямую: публичный контракт должен быть API или событием.

Проверка - consumer-driven contract tests или совместимость producer/consumer схем. Перед релизом надо убедиться, что старая версия producer работает с новой версией consumer и наоборот, если такой режим возможен во время rolling deploy. Для событий полезны правила backward compatibility: добавление optional поля обычно безопаснее, переименование или удаление поля - breaking change.

Документация контракта должна жить рядом с кодом или в registry, а не только в устной договоренности. Для миграций нужен план: dual-write, dual-read, deprecation period и мониторинг ошибок парсинга.

CPU дает максимум 20 одновременных документов, RAM в worst case дает floor(64 / 4) = 16. Safe concurrency равна 16, throughput = 16 / 2 = 8 документов в секунду.

Сначала надо разделить concurrency и throughput. Один документ держит один CPU core и до 4 GB RAM на все время обработки. CPU разрешает держать одновременно 20 документов, но память разрешает только floor(64 / 4) = 16 документов в worst case.

Значит, реальный safe bottleneck - RAM. При concurrency 16 и времени обработки 2 секунды throughput равен 16 / 2 = 8 документов в секунду.

Если брать optimistic estimate 3.5 GB на документ, память дала бы floor(64 / 3.5) = 18 документов и 9 документов в секунду. Но для safe ответа на собеседовании лучше брать worst-case потребление 4 GB.

Для 1 consumer вся работа последовательна: 90 * 0.09 + 10 * 1 = 18.1 s. Для 10 consumers best case 1.81 s, если долгие задачи распределены по одной на partition; worst case 10 s, если все долгие задачи попали в одну partition. Для 20 consumers так же, потому что partitions всего 10.

Сначала считаем суммарную работу: 90 быстрых задач по 0.09 секунды дают 8.1 секунды, 10 долгих задач по 1 секунде дают 10 секунд. Всего 18.1 секунды последовательной работы.

При 1 consumer все partitions фактически обрабатываются одним worker-ом, поэтому best и worst одинаковые: 18.1 секунды.

При 10 consumers каждая partition может получить своего consumer-а. Best case: долгие задачи распределены равномерно, по одной на partition. Тогда каждая partition занимает 1 + 9 * 0.09 = 1.81 секунды, и вся группа заканчивает за 1.81 секунды. Worst case: все 10 долгих задач попали в одну partition; эта partition становится bottleneck и занимает 10 секунд.

При 20 consumers результат не улучшается: одна partition назначается максимум одному consumer-у, поэтому полезный параллелизм ограничен 10 partitions.