Разборы System Design SDC · 01 · 07

Фундаментальные кейсы: чтение чисел и конфига

Читай реальную математику ёмкости и конфиг из четырёх кейсов и считай: проверка пересечения кворума, оценка QPS/keyspace сокращателя, размер bloom filter краулера и расчёт числа партиций Kafka.

SDC Senior ◷ 14 min

Уровень

ОсновыJuniorMiddleSenior

Баги дизайна прячутся в числах, не в прозе: кворум, что не пересекается, QPS, ошибающийся на 10^5, bloom filter, размеренный под неверную долю ошибок, число партиций, ограничивающее пропускную способность. Читай каждый сниппет, считай в уме и выбери ответ, под которым подпишется senior-инженер.

Практикуй цикл, что крутишь на ревью дизайна: найди числа в конфиге, примени правило (пересечение кворума, daily-в-QPS, биты bloom filter, пропускная способность партиции) и выбери изменение, которое арифметика реально поддерживает.

Сниппет 1 — конфиг кворума

# распределённое KV-хранилище
replication_factor_N: 3
write_quorum_W: 1
read_quorum_R: 1
# "настроено под низкую задержку"

Викторина

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

Сниппет 2 — оценка сокращателя

def shortener_capacity(new_urls_per_month: float, read_write_ratio: float = 100):
    writes_per_sec = new_urls_per_month / (30 * 86_400)
    reads_per_sec = writes_per_sec * read_write_ratio
    return round(writes_per_sec), round(reads_per_sec)

# 100 миллионов новых URL/месяц
print(shortener_capacity(100_000_000))

Викторина

Примерно что вернёт shortener_capacity(100_000_000) и какое число диктует архитектуру?

Сниппет 3 — размер bloom filter

# множество виденных URL краулера
exact_set_urls = 10_000_000_000       # 10 миллиардов виденных URL
bytes_per_url_exact = 100             # ~100 байт/URL точно
bits_per_url_bloom = 10               # цель ~1% ложно-положительных

exact_ram_bytes = exact_set_urls * bytes_per_url_exact
bloom_ram_bytes = exact_set_urls * bits_per_url_bloom / 8

Викторина

Примерно сколько RAM нужно каждому подходу и чего стоит bloom filter?

Сниппет 4 — число партиций Kafka

# размер Kafka-подобного топика
target_throughput_mb_s = 1000     # ~1 ГБ/с на пике
per_partition_mb_s = 10           # потолок упорядоченной реплиц. записи на партицию
consumers_in_group = 8

partitions_needed = target_throughput_mb_s / per_partition_mb_s

Викторина

Сколько партиций нужно этому топику и каково последствие для группы из 8 консьюмеров?

Вспомните перед уходом

01
Как проверить, что конфиг кворума даёт read-your-write, и в чём ловушка?
02
Как размерить bloom filter краулера и сколько партиций Kafka под цель пропускной способности?

Итог

Каждое решение дизайна в этих кейсах сводится к арифметике, что читаешь прямо с конфига. Проверка кворума — R + W > N: конфиг W=1, R=1 при N=3 суммируется в 2 ≤ 3, так что чтения могут промахиваться мимо записей — чини W=2, R=2. Оценка сокращателя переводит 100M URL/месяц в ~40 записей/с и, при 100:1, ~4 000 чтений/с — и число чтений диктует архитектуру кеш-и-редирект. Размер bloom filter показывает, что ~10 бит/URL дают ~12,5 ГБ для 10 миллиардов URL против ~1 ТБ точно (~80x меньше), ценой малой доли ложно-положительных. Число партиций — цель пропускной способности ÷ потолок на партицию (1000 ÷ 10 ≈ 100 партиций), что также ограничивает параллелизм консьюмеров числом партиций. Senior-привычка одна и та же для всех четырёх: найди числа, посчитай, следи за единицами и выбери починку, что поддерживает арифметика — а не ту, что её прячет.

Что-то непонятно?

Задай вопрос по этому уроку. Вопросы анонимны и попадают напрямую автору — урок станет лучше.