Что хотят услышать интервьюеры:

Сначала нужно локализовать задержку: это сам Python-код, сеть, middleware, сериализация или внешние вызовы до БД. Дальше важно измерять время по этапам, а не смотреть только на итоговый latency эндпоинта. Обычно начинают с логов, трассировки и профилирования, чтобы быстро понять, где именно теряется время.

Определение:

Диагностика задержки до обращения к базе данных — это поэтапное измерение и анализ всех частей обработки запроса до момента старта SQL-запроса. Цель — отделить накладные расходы приложения от проблем БД и выяснить, в каком месте запрос “застревает”: в роутинге, валидации, сериализации, вызовах внешних сервисов, синхронном I/O или блокировках.

Пример использования:

Если API-эндпоинт отвечает за 800 мс, а к базе он обращается только через 500 мс после входа запроса, сначала логируют время на каждом этапе и добавляют простую трассировку. Это показывает, что 300–500 мс уходят, например, на валидацию payload, чтение из кэша, вызов другого сервиса или ожидание свободного worker-а.

import time
import logging

logger = logging.getLogger(__name__)

def endpoint_handler(request):
    t0 = time.perf_counter()

    logger.info("start request")

    t1 = time.perf_counter()
    data = parse_request(request)
    logger.info("parse_request: %.3f ms", (time.perf_counter() - t1) * 1000)

    t2 = time.perf_counter()
    validated = validate(data)
    logger.info("validate: %.3f ms", (time.perf_counter() - t2) * 1000)

    t3 = time.perf_counter()
    prepared = prepare_context(validated)
    logger.info("prepare_context: %.3f ms", (time.perf_counter() - t3) * 1000)

    logger.info("time before DB: %.3f ms", (time.perf_counter() - t0) * 1000)

    # дальше уже идет запрос к БД
    result = query_database(prepared)

    logger.info("total handler time: %.3f ms", (time.perf_counter() - t0) * 1000)
    return result

Пояснение кода:

Код нужен как пример ручной сегментации времени.
Шаг 1: фиксируется старт запроса через perf_counter(), чтобы получить точное измерение интервалов.
Шаг 2: каждый этап обработки оборачивается в отдельный замер, чтобы увидеть, где уходит время до БД.
Шаг 3: логируется суммарное время до начала SQL-запроса — это помогает понять, проблема внутри приложения или уже на стороне базы.
Шаг 4: если один из этапов стабильно занимает много времени, его отдельно профилируют и проверяют на лишние вычисления, блокировки, сетевые вызовы или синхронное ожидание.

Ключевые моменты:

Измерять не только total latency, но и время каждого этапа до БД.
Проверять, нет ли скрытых внешних вызовов, I/O или тяжелой валидации до SQL.
Сравнивать поведение на “плохих” и “хороших” запросах, чтобы найти закономерность.
Использовать логи, трассировку и профилирование, а не только интуицию.
Отдельно смотреть на блокировки, ожидание worker-а и перегрузку приложения.
После локализации узкого места уже решать: оптимизация кода, кэш, асинхронность или изменение архитектуры.

Какие шаги ты бы предпринял, чтобы диагностировать источник задержки ответа эндпоинта перед выполнением запросов к базе данных?