System Design

Сегодня у нас уровень Hard, одна из самых сложных задач System Design, которую обычно дают на Staff+ уровне. 

Мы спроектируем распределенный планировщик задач - систему, которая запускает задания по расписанию или в нужное время. Она должна масштабироваться до 10 тысяч запусков в секунду, стартовать задачи с точностью до 2 секунд и не терять их, даже если воркер упадет во время работы.

В статье разберем, как:

• хранить описание задачи отдельно от расписания ее запусков и партиционировать базу, чтобы быстро находить ближайшие задания
• запускать задачи с точностью до 2 секунд и не перегружать базу частыми запросами, используя буферную очередь с отложенной доставкой
• отслеживать упавшие воркеры и перезапускать задачи через таймаут видимости в очереди вместо постоянных проверок каждого сервера
• защититься от повторного выполнения одной и той же задачи

Как Shopify перенес резервирование товаров из Redis в MySQL

Shopify обрабатывает более 14% всех транзакций в сфере электронной коммерции в США. Чтобы последний оставшийся товар не был продан двум покупателям одновременно, каждое оформление заказа защищено системой резервирования. Когда покупатель переходит к оплате, Shopify резервирует выбранные товары на несколько минут. Если платеж проходит успешно, Shopify окончательно списывает их из системы складского учета продавца.

Годами эти два шага выполнялись в разных базах данных. Redis отслеживал, сколько единиц товара покупатели временно зарезервировали, а MySQL вел учет реального количества товаров на складе продавца. Так как ни одна транзакция не могла атомарно обновить обе базы, сбой между двумя записями приводил к рассинхронизации: система либо скрывала товар, который на самом деле был доступен, либо позволяла продать то, чего на складе уже не осталось.

Shopify перенес резервирование из Redis в MySQL, и теперь обе операции выполняются в рамках одной транзакции. Вместо одной строки на товар со счетчиком доступного остатка система использует ограниченный пул строк, где каждая строка представляет одну единицу товара, доступную для бронирования. Благодаря механизму SKIP LOCKED в MySQL 8 параллельные покупатели могут захватывать разные строки, не дожидаясь друг друга, а процесс пополнения не дает пулу разрастаться до масштабов всего складского запаса продавца. Переработанная система успешно выдержала Черную пятницу 2025 года, когда продажи на пике достигли рекордных 5,1 миллиона долларов в минуту.

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

Проблема

Представьте распродажу: осталась всего одна толстовка, и два покупателя одновременно нажимают кнопку оплаты. Shopify должен гарантировать, что купить ее сможет только один из них.

В этом и заключается задача механизма защиты от перепродажи (oversell protection). Когда покупатель начинает оплату, система резервирует товары на несколько минут, чтобы никто другой не мог их забрать, пока обрабатывается платеж. Если платеж проходит успешно, Shopify окончательно вычитает эти позиции из складского остатка продавца. Если платеж завершается ошибкой или истекает таймаут, система [... читать дальше]

Когда мы слышим Redis, обычно первое, что приходит на ум - это кэш.
Но Redis удивительно простая и при этом универсальная технология, которую можно применять для широкого круга задач.

В новом видео за 36 минут кратко разобрали все что нужно знать про Redis для System Design: https://www.youtube.com/watch?v=mlIB7AOG-GU

Рассмотрели 7 различных сценариев Redis: 
• cache
• rate limiter
• leaderboards / priority queues
• geosearch
• distributed locks
• Streams
• Pub/Sub

Сегодня разберем систему, которая должна максимально масштабироваться, причем как для чтения, так и для записи.

Будем проектировать NewRelic / Datadog - платформу для мониторинга метрик, которая способна принимать до 5 млн метрик в секунду с 500 тыс серверов.

Рассмотрим как:

• принимать 5 млн метрик в секунду, используя агенты с локальной буферизацией
• выдавать аналитику для дашбордов, используя заранее посчитанные агрегации и кэширование
• обеспечить срабатывание оповещений менее чем за 1 минуту
• бороться с взрывом кардинальности - типичной проблемой таких систем

Как Discord перенес триллионы сообщений в ScyllaDB

В начале 2022 года Discord хранил триллионы сообщений на 177 узлах Cassandra. Cassandra отлично подходила для высокой нагрузки на запись. Проблема была в чтении: популярный канал мог отправлять тысячи запросов на чтение сообщений. Все они шли к одному разделу, перегружали его и тормозили запросы других каналов на тех же серверах. К тому же уплотнение данных (compaction) постоянно отставало, а паузы сборщика мусора JVM приводили к скачкам задержек.

Чтобы решить проблемы на уровне базы данных, Discord заменил Cassandra на ScyllaDB - совместимую реализацию на C++. Она избавила систему от пауз сборщика мусора JVM, сделала хранилище быстрее и проще в обслуживании.

Но более быстрая база данных не защищает от ситуации, когда тысячи людей одновременно запрашивают одно и то же сообщение. Для этого Discord поставил перед базой данных сервисы данных на Rust. Запросы одного канала направляются на один экземпляр сервиса, где параллельные чтения одного сообщения объединяются в один запрос к базе данных.

Новый кластер работает на 72 узлах вместо 177, а p99 времени чтения упал со 125 мс до стабильных 15 мс.

Проблема

Discord хранил сообщения в Cassandra с 2017 года. К началу 2022 года кластер вырос до 177 узлов с триллионами сообщений. Все они хранились в одной таблице:

CREATE TABLE messages (
channel_id bigint,
bucket int,
message_id bigint,
author_id bigint,
content text,
PRIMARY KEY ((channel_id, bucket), message_id)
) WITH CLUSTERING ORDER BY (message_id DESC);

В Cassandra составной ключ (channel_id, bucket) служит ключом партиционирования и определяет, на каких серверах лежат данные. Канал - это чат на сервере Discord, а bucket - окно времени. Вместе они собирают сообщения канала за определенный период в один раздел, который реплицируется на [... читать дальше]

Понимаю, что для вас это детский лепет, но если кому-то надо быстро обновить \ систематизировать базу по теме Кэширование, то для вас новый видос https://www.youtube.com/watch?v=H1sr4BuOatI

За 35 минут рассматриваем самые главные темы: от паттернов кеширования (cache-aside, write-through, write-behind, и тд) до частых проблем (cache stampede, consistency, hot keys).

Скоро кончится лето... пора потихоньку готовиться к собесам.

Представьте, что вы проходите собес в Stripe (хотя, кого я обманываю, это будет Сбер и их ЮКасса) и на секции System Design вам дают задачу - спроектировать платежную систему, которая выдержит 10 тысяч транзакций в секунду, сохранит полный аудит каждой операции и не спишет платеж с клиента дважды.

В статье разберем, как:

• избегать попадания данных карты на серверы продавца, используя iframe и шифрование на клиенте
• строить неизменяемый аудиторский след через CDC и поток событий в Kafka
• не считать таймаут платежной сети сбоем и автоматически сверять спорные платежи
• шардировать базу по merchant_id и партиционировать Kafka по payment_intent_id, чтобы держать 10 тысяч TPS и не ломать порядок событий внутри одного платежа

Воскресный подгон по System Design, я не знаю, как подогреть вас круче.

Представьте, вы проходите собес в OpenAI и на секции System Design вам дают задачу - спроектировать ChatGPT, но не с точки зрения обучения модели, а с точки зрения инфраструктуры необходимой для GPU-инференса и поддержки 200 млн пользователей ежедневно и 20 тыс запросов на генерацию в секунду.

В статье разберем, как:

• отдавать первый токен за 500 мс через SSE и не держать лишние соединения
• эффективно загружать GPU-воркеры с помощью очереди и непрерывной пакетной обработки (continuous batching)
• как проектировать квоты и приоритетные очереди для разных тарифов
• контролировать расходы на инференс в длинных диалогах с помощью KV-кэширования и скользящего окна

Как спроектировать сервис для поиска и оценки заведений, такой как Yelp, который выдержит 100 млн пользователей в день?

В подробном разборе - быстрый геопоиск, рейтинги без гонок данных, Elasticsearch vs Postgres и решения, которые ждут на интервью.
Бонусом идет видеоразбор для тех кто не любит читать.

Premium статья доступна бесплатно только для подписчиков этого канала: Проектируем Yelp

Собрались как то Staff Engineer из FIvetran, Senior Engineer из Yandex и VP of Engineering из Proximie и решили сделать новую платформу, где можно быстро подготовиться к собесу: NowInterview

Для тех, кто устал от шаблонных объяснений для каждой задачи

добавим балансировщик, кэш, шардирование

и хочет разобраться как действительно работают реальные системы и как в них решены самые сложные вопросы:

• как динамически конфигурировать правила через ZooKeeper для Rate Limiter?
• как избежать повторного показа профилей с помощью фильтров Блума в Tinder?
• как реализовать возобновляемую загрузку файлов по 50ГБ в Dropbox?
• как предотвратить назначение нескольких поездок одному водителю через распределенную блокировку в Uber?
• как реализовать совместное редактирование через CRDT+Websocket в Google Docs?
• как запускать 10k заданий в секунду точно в указанное время в Job Scheduler?

Кто не любит читать — можно глянуть видосы на их YouTube-канале.

Для тех, кто только вкатывается в тему - бесплатные материалы, которые объясняют на понятном языке с самых основ, что такое System Design, что ждет интервьюер и как не завалить собес - Кратко

Ну и если вы прошарены настолько, что готовы углубиться в реально серьезные темы, такие как паттерны масштабирования, обновления в реальном времени, управление конкуренцией и пройти практику System Design собеса по всем задачам выше, то для вас промокод на 25% на подписку Premium.

Промокод: MAX (-25% на все планы, действует бессрочно)