Но в нашем случае он потребовал бы реализации push-механизма доставки данных, а текущие характеристики pull-модели нас полностью устраивают. Мы стараемся не усложнять систему там, где этого не требуется.
Гибридная схема pull + push это классический подход для случаев, когда критична задержка доставки изменений. Мы её рассматривали, но там сразу появляются сложности, описанные в разделе про push на основе gRPC-стриминга. Задержки в одну‑две секунды нас полностью устраивали, всё уже работало на чистом pull, поэтому мы не стали усложнять систему без явной потребности. Если в будущем понадобится мгновенная актуализация, то вполне возможно, что как раз и придём к гибриду.
В финальной схеме посредник действительно мог бы быть исключён, но мы осознанно его оставили. Во-первых, он инкапсулирует всю логику работы с этой БД и S3 (наполнение, версионирование, создание снапшотов). Клиентам не нужно знать ни SQL, ни структуру таблиц, только gRPC-контракт моделей. Во-вторых, у нас уже была готовая интеграция с ним, и нам оставалось лишь подменить вызовы ручек.
Репликация БД это прекрасный механизм, и в наших базах он используется. Но увеличение числа реплик не решает главной проблемы: нам нужно за минимальное время получить данные о тысячах складов. Даже батчевые ручки других наших сервисов, отдающие данные по ключу, работают в пределах 30–50 мс с пачками по сто элементов. Если мы будем тратить столько времени только на получение данных, то сильно превысим SLO (и это ещё для сотни элементов, а у нас в запросе их тысячи). Поэтому мы держим данные прямо в памяти пода, обрабатывающего запрос.
Но в нашем случае он потребовал бы реализации push-механизма доставки данных, а текущие характеристики pull-модели нас полностью устраивают. Мы стараемся не усложнять систему там, где этого не требуется.
Гибридная схема pull + push это классический подход для случаев, когда критична задержка доставки изменений. Мы её рассматривали, но там сразу появляются сложности, описанные в разделе про push на основе gRPC-стриминга. Задержки в одну‑две секунды нас полностью устраивали, всё уже работало на чистом pull, поэтому мы не стали усложнять систему без явной потребности. Если в будущем понадобится мгновенная актуализация, то вполне возможно, что как раз и придём к гибриду.
В финальной схеме посредник действительно мог бы быть исключён, но мы осознанно его оставили. Во-первых, он инкапсулирует всю логику работы с этой БД и S3 (наполнение, версионирование, создание снапшотов). Клиентам не нужно знать ни SQL, ни структуру таблиц, только gRPC-контракт моделей. Во-вторых, у нас уже была готовая интеграция с ним, и нам оставалось лишь подменить вызовы ручек.
Репликация БД это прекрасный механизм, и в наших базах он используется. Но увеличение числа реплик не решает главной проблемы: нам нужно за минимальное время получить данные о тысячах складов. Даже батчевые ручки других наших сервисов, отдающие данные по ключу, работают в пределах 30–50 мс с пачками по сто элементов. Если мы будем тратить столько времени только на получение данных, то сильно превысим SLO (и это ещё для сотни элементов, а у нас в запросе их тысячи). Поэтому мы держим данные прямо в памяти пода, обрабатывающего запрос.