Кейс: шардирование по created_at собрало весь трафик на одном шарде

Range-based sharding раскладывает данные по диапазонам ключа — например, по дате создания записи. Каждый шард отвечает за свой интервал времени, и это удобно для range-запросов: «заказы за последний месяц» читаются с одного-двух шардов, а не со всех сразу.

Проблема вылезает на write-пути. Если ключ шардирования — created_at, все новые записи попадают в шард с текущим диапазоном. Пока не наступит следующий интервал, весь write-трафик системы идёт в один шард, а остальные простаивают.

Симптом на графиках — asymmetric load: у одного шарда CPU и disk IO забиты, у соседних почти ноль. Ротация на новый шард по времени не размазывает нагрузку — просто переносит hot spot на следующий шард по расписанию.

Что спросят следом: как исправить, не теряя range-запросы. Рабочий вариант — составной ключ шардирования: hash от entity_id в паре с диапазоном по времени, где entity_id даёт равномерность записи, а диапазон по времени всё ещё позволяет ужимать range-сканы внутри шарда через вторичный индекс.

Consistent hashing по entity_id решает проблему hot shard на запись, но убивает дешёвые range-запросы по времени — этот трейд-офф стоит проговорить на собеседовании явно, а не выбирать один инструмент как универсальный.

Тренажёр: 600 вопросов, мок с таймером, план повторов

senior·base — что спрашивают на самом деле

В этом посте были ссылки, но мы их удалили по правилам Сетки