Этот раздел можно читать до запуска опыта. После теории вернитесь к live trace и сопоставьте каждый шаг с реальным событием.
System Design — это не угадывание модных технологий на доске. Сначала вы выясняете, что должен уметь продукт, сколько людей и данных он обслуживает и какую задержку или потерю он может пережить. Затем рисуете путь запроса, находите состояние и самые узкие места и только после этого выбираете балансировщик, кэш, базу, очередь или несколько реплик.
Проектирование системы связывает functional requirements с quality attributes: latency, availability, durability, consistency, security и cost. Численные оценки задают порядок величин, SLI измеряет наблюдаемое поведение, SLO задаёт целевой уровень, а архитектурные решения перераспределяют конкретные риски. Горизонтальное масштабирование помогает лишь stateless-слою; состояние, горячие ключи и downstream limits требуют отдельного дизайна.
Сначала поймите слова — затем порядок выполнения.
Процесс проектирования компонентов, данных и взаимодействий системы под явные требования, ограничения и failure modes.
Пользовательская возможность или business rule: загрузить документ, оформить заказ, найти публикацию.
Измеримое свойство системы: latency, availability, durability, consistency, security или стоимость.
SLI — измерение, SLO — внутренняя цель для него, SLA — договорное обещание с последствиями нарушения.
Throughput — завершённая работа за единицу времени; concurrency — работа, одновременно находящаяся в системе.
Принимает трафик и распределяет его между здоровыми replicas; сам по себе не масштабирует базу или shared state.
Добавление экземпляров сервиса. Проще для stateless API, сложнее для stateful компонентов и фоновой работы.
Механизм, который не позволяет producer бесконечно подавать работу быстрее, чем consumer способен обработать.
Replication создаёт копии данных для доступности и чтения; partitioning делит набор данных между узлами.
RPO ограничивает допустимую потерю данных по времени, RTO — допустимое время восстановления сервиса.
Повтор операции с тем же ключом не создаёт второй business effect — критично при timeout и retry.
Каждый шаг соответствует наблюдаемому состоянию runtime.
Назовите actors, операции чтения и записи, данные и то, что сознательно не проектируется в этой версии.
Например: 99% чтений быстрее 300 мс за 28 дней, не более 0.1% ошибок и RPO не хуже пяти минут.
Из DAU, действий на пользователя, peak factor и размера payload получите средний/пиковый RPS, storage и bandwidth.
Покажите client, edge/load balancer, API, cache, primary database, replicas, queue, workers и внешние зависимости.
Для каждой записи решите источник истины, ключ доступа, consistency boundary, lifecycle и способ восстановления.
Проверьте timeout, duplicate, partial failure, перегрузку, stale cache, lag реплики, потерю зоны и poison message.
Load test, p95/p99, saturation, queue depth, error rate, fault injection и restore drill проверяют гипотезу лучше стрелок.
Эти детали объясняют, почему похожий код иногда даёт другой trace.
Средний RPS за сутки может быть небольшим, пока рекламная рассылка создаёт десятикратный всплеск за минуту.
Он уменьшает нагрузку и latency, но добавляет TTL, invalidation, stampede и возможность устаревшего ответа.
Без deadline, exponential backoff и jitter повторные запросы усиливают аварию и создают retry storm.
Она поглощает короткий всплеск. Если входящий rate постоянно выше обработки, backlog и время ожидания растут без границы.
Read replica масштабирует чтение, но read-after-write может потребовать primary или механизма session consistency.
Он добавляет сетевую задержку, conflict resolution, сложный failover, стоимость и необходимость регулярно проверять recovery.
Сначала разберитесь, какие части Node участвуют в выполнении.
Затем уберите служебные детали и рассмотрите только главную идею.
После этого сопоставьте модель с кодом, который создаёт live trace.
const requestsPerDay = dau * actionsPerUser;
const averageRps = requestsPerDay / 86_400;
const peakRps = averageRps * peakFactor;
const replicas = Math.ceil(
peakRps / (rpsPerReplica * targetUtilization),
);Это не альтернативный пример: ниже показаны функции и файлы, используемые кнопкой запуска.
Код сформирован из реальной серверной функции. Для сценариев с отдельным процессом или Worker показаны все участвующие файлы.
const SECONDS_PER_DAY = 86_400;
const BITS_PER_BYTE = 8;
export function estimateCapacity({
dailyActiveUsers,
actionsPerUser,
peakFactor,
averagePayloadKb,
rpsPerReplica,
targetUtilization,
}) {
const requestsPerDay = dailyActiveUsers * actionsPerUser;
const averageRps = requestsPerDay / SECONDS_PER_DAY;
const peakRps = averageRps * peakFactor;
const peakMegabitsPerSecond =
(peakRps * averagePayloadKb * 1024 * BITS_PER_BYTE) / 1_000_000;
const usableRpsPerReplica = rpsPerReplica * targetUtilization;
const servingReplicas = Math.max(
1,
Math.ceil(peakRps / usableRpsPerReplica),
);
return {
requestsPerDay: Math.round(requestsPerDay),
averageRps: Number(averageRps.toFixed(1)),
peakRps: Number(peakRps.toFixed(1)),
peakMegabitsPerSecond: Number(peakMegabitsPerSecond.toFixed(1)),
servingReplicas,
replicasWithOneFailure: servingReplicas + 1,
};
}
export async function systemDesignCapacity(emit) {
const assumptions = {
dailyActiveUsers: 120_000,
actionsPerUser: 35,
peakFactor: 8,
averagePayloadKb: 6,
rpsPerReplica: 250,
targetUtilization: 0.6,
};
emit(
'requirements',
'input',
'Цель: выдержать пользовательский пик и потерю одной API replica',
);
emit(
'capacity',
'assumption',
`Предположения: DAU=${assumptions.dailyActiveUsers}, действий/пользователь=${assumptions.actionsPerUser}, peak factor=${assumptions.peakFactor}`,
);
const estimate = estimateCapacity(assumptions);
emit(
'capacity',
'result',
`Среднее=${estimate.averageRps} RPS; проектный пик=${estimate.peakRps} RPS; egress≈${estimate.peakMegabitsPerSecond} Mbit/s`,
);
emit(
'api-tier',
'headroom',
`Нужно ${estimate.servingReplicas} serving replicas при 60% target utilization; N+1=${estimate.replicasWithOneFailure}`,
);
emit(
'database',
'constraint',
'Расчёт API не доказывает capacity базы, connection pool, cache или downstream',
);
emit(
'validation',
'next-step',
'Следующий шаг: load test с реальным traffic mix и проверкой p95/p99, ошибок и saturation',
);
return estimate;
}
Live trace инструментирован самим приложением: строки и timestamps фиксируются при реальных вызовах emit(...), а названия source/lane задаёт сценарий. Это не profiler V8/libuv и не прямой снимок их внутренних очередей. await и Promise удерживают HTTP-поток открытым до завершения сценария.
Сравнивайте цель, код и оговорки — не запоминайте синтаксис без модели.
Получить порядок peak RPS до выбора количества replicas.
const requestsPerDay = dau * actionsPerUser;
const averageRps = requestsPerDay / 86_400;
const peakRps = averageRps * peakFactor;
const replicas = Math.ceil(
peakRps / (rpsPerReplica * targetUtilization),
);Безопасно пережить повтор POST после timeout клиента.
INSERT INTO payments (idempotency_key, order_id, amount)
VALUES ($1, $2, $3)
ON CONFLICT (idempotency_key) DO NOTHING
RETURNING id, status;Не ждать downstream бесконечно и не устроить retry storm.
const response = await fetch(url, {
signal: AbortSignal.timeout(800),
});
if (response.status >= 500 && attempt < 2) {
await sleep(backoffWithJitter(attempt));
}Защитить базу от неограниченной параллельности workers.
new Worker('previews', renderPreview, {
connection,
concurrency: 8,
limiter: { max: 40, duration: 1_000 },
});Убрать неготовый Pod из трафика, не перезапуская его без причины.
@Get('/ready')
ready() {
return this.dependencies.canServeTraffic()
? { status: 'ready' }
: (() => { throw new ServiceUnavailableException(); })();
}Реалистичный сервис: исходный код, наблюдаемая проблема, исправление и причина, по которой оно работает.
Nest endpoint строит тяжёлый отчёт и ждёт внешний storage; при всплеске все HTTP workers удерживают соединения.
Latency растёт до timeout, клиенты повторяют POST, один отчёт создаётся несколько раз, а database pool заканчивается.
@Post(':id/export')
async export(@Param('id') id: string) {
const rows = await this.reports.loadAllRows(id);
const file = await this.renderer.render(rows);
return this.storage.upload(file);
}Долгая CPU/I/O-цепочка привязана к request lifetime, не имеет idempotency key, bounded concurrency и отдельного capacity budget.
@Post(':id/export')
@HttpCode(202)
async export(
@Param('id') id: string,
@Headers('idempotency-key') key: string,
) {
const job = await this.exports.enqueueOnce({ reportId: id, key });
return { jobId: job.id, statusUrl: '/exports/' + job.id };
}
@Processor('exports')
export class ExportWorker extends WorkerHost {
async process(job: Job<ExportJob>) {
return this.exports.buildAndStore(job.data);
}
}HTTP быстро подтверждает приём, durable queue буферизует пик, уникальный ключ дедуплицирует повтор, а Worker concurrency защищает database и storage.
Что делают непривычные вызовы из обоих фрагментов кода.
@HttpCode(202)@Headers()enqueueOnce()WorkerHost.process()После создания публикации UI сразу запрашивает её, а случайный балансировщик чтений отправляет запрос на отстающую replica.
Пользователь периодически получает 404 для только что созданного объекта, хотя запись успешно commit-нулась на primary.
@Get(':id')
findOne(@Param('id') id: string) {
return this.randomReplica.query(
'SELECT * FROM articles WHERE id = $1',
[id],
);
}Replica выбирается без учёта replication lag и пользовательского read-after-write ожидания.
@Get(':id')
findOne(
@Param('id') id: string,
@Headers('x-read-token') token?: string,
) {
const db = token && this.readTokens.isFresh(token)
? this.primary
: this.replica;
return db.query(
'SELECT * FROM articles WHERE id = $1',
[id],
);
}После записи короткоживущий token направляет связанные чтения на primary; остальные масштабируемые чтения остаются на replica.
Что делают непривычные вызовы из обоих фрагментов кода.
x-read-tokenisFresh()this.primarySQL $1Миф слева, корректная модель справа.
System Design — это нарисовать побольше boxes.
Диаграмма полезна только вместе с требованиями, числами, владельцами состояния, failure modes и проверяемыми trade-offs.
Load balancer автоматически делает систему масштабируемой.
Он распределяет трафик, но shared database, lock, hot key или внешний API могут остаться единственным bottleneck.
Две replicas означают 100% availability.
Одинаковая ошибка deploy, общая зона, corrupt data или неверный failover способны вывести из строя обе копии.
Если есть backup, данные защищены.
Нужны измеримые RPO/RTO, независимое хранение, проверка целостности и регулярно отрепетированный restore.
Autoscaling решает любую перегрузку.
Масштабирование запаздывает и может лишь быстрее перегрузить database или downstream без admission control и backpressure.
Если ответ получается объяснить без терминов из документации, ментальная модель уже начала складываться.