Как устроены большие сервисы — и как строить их с нейросетями

Как читать

Правило этой школы: каждое утверждение помечено, откуда оно. Мнение нейросети фактом не считается — в том числе моё.

Новые слова выделены жирным, рядом в скобках — английский термин: под ним это слово живёт в документации и в ответах нейросети. Все термины собраны в словаре.

1С чего начинается архитектура

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

Архитектор не рисует систему, которая «выдержит всё». Он отвечает на четыре вопроса — цифрами.

1. Что сломается первым? У любой системы есть самое узкое место (bottleneck). Его надо знать заранее, а не узнать из жалобы.
2. При какой цифре? «Когда вырастем» — не ответ. «При 40 запросах в секунду к одной копии сервера» — ответ.
3. Сколько стоит поломка? Витрина лежит час — потеряны продажи за час. Потеряны деньги покупателя или база заказов — потеряно доверие, это дороже на порядки.
4. Что самое дешёвое можно сделать сейчас, чтобы поломка стала переносимой?

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

2Прикидка на салфетке

Первый навык — быстро перевести бизнес-цель в нагрузку. Нагрузку меряют в запросах в секунду (RPS) и всегда считают пик, а не среднее: система падает в пике.

Цель «300 000 покупок в месяц». Допущения грубые, важен порядок величин.

Посмотри на две жирные цифры. Заказов — один-два в секунду. Запросов чтения — тысяча. Разница в 500–1 000 раз. Из неё следует всё остальное.

3Две задачи: чтение и деньги

Тонкая полоска справа — деньги и заказы.

4Путь одного запроса

Человек открыл карточку товара. Вот через что проходит его запрос в большой системе. Практика отрасли

5Три рычага. Других нет

Когда системе не хватает мощности, способов ровно три, и применяют их в таком порядке.

1. Не делать работу. Ответ, который считали минуту назад, отдать готовым. Это кэш. Самый дешёвый рычаг: хороший кэш снимает 80–95 % нагрузки чтения.
2. Делать работу дешевле. Найти, на что уходит время одного запроса, и убрать лишнее: лишний поход в базу, тяжёлый расчёт, отсутствующий индекс.
3. Добавить работников. Поставить больше одинаковых копий сервера.

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

Третий рычаг бывает двух видов. Вверх (vertical scaling) — машина мощнее: просто, но у железа есть потолок. Вширь (horizontal scaling) — больше машин: потолка почти нет, но система должна это уметь.

6Состояние — главное слово

Состояние (state) — всё, что система обязана помнить: заказы, остатки, кто вошёл, что лежит в корзине.

Представь магазин. Кассиры ничего не помнят сами — всё записано в одной общей книге. Нужен ещё кассир — ставишь, и он сразу работает: любой кассир обслужит любого покупателя. Это копия приложения без состояния (stateless). А книга одна. Её нельзя просто размножить: если две книги разойдутся, непонятно, какой верить. Это база данных.

7Кэш: рычаг номер один

Кэш (cache) — место, где лежит готовый ответ, чтобы не считать его заново. Кэшей несколько, они стоят слоями:

• в браузере и приложении — картинка, которую телефон уже скачал;
• в сети доставки — готовая страница каталога на сервере рядом с человеком;
• в быстрой памяти — результат тяжёлого запроса к базе;
• в самой базе — заранее посчитанные таблицы, например счётчики по дням.

Качество кэша меряют долей попаданий (cache hit rate): сколько запросов из ста получили готовый ответ. 90 % попаданий — значит, до сервера доходит каждый десятый запрос.

Цена кэша одна: ответ может устареть. Человек видит «в наличии», а товар купили минуту назад. С этим борются двумя способами: сроком жизни записи (TTL — «через 60 секунд спроси заново») и сбросом при изменении (invalidation — «товар изменился, выбрось старое»). Второе точнее и заметно сложнее.

8База данных

База — это книга учёта, которая не врёт. Четыре слова, без которых её не понять:

• Транзакция (transaction) — несколько изменений как одно: либо записались все, либо ни одного. Списать остаток и создать заказ — одна транзакция. Не бывает «остаток списан, заказа нет».
• Индекс (index) — оглавление к таблице. С ним база находит строку сразу, без него читает всё подряд. Отсутствующий индекс — самая частая причина «вдруг стало медленно».
• Блокировка (lock) — пока один покупатель оформляет последнюю штуку, второй ждёт. Так не продают один товар дважды.
• Миграция (migration) — изменение устройства таблиц. На живой системе её делают в три шага: добавили новое, перевели на него код, убрали старое. Иначе во время выкатки одна версия кода не поймёт таблицы другой.

Лестница базы

Базу масштабируют последней, и ступени обычно идут в таком порядке. Каждая следующая заметно дороже предыдущей. Практика отрасли

9Очереди и фоновая работа

Человек нажал «оформить». Ему нужен ответ «заказ принят» за полсекунды. А письмо продавцу, уведомление, пересчёт статистики могут подождать. Такую работу кладут в очередь (queue), и её разбирают работники (workers) — отдельные процессы.

Очередь даёт три вещи: быстрый ответ человеку, сглаживание пиков (в распродажу очередь растёт, но ничего не падает) и повтор при сбое.

За это платят одним неприятным свойством. Сеть ненадёжна: работник мог выполнить задачу и не успеть об этом сообщить. Очередь не знает, сделано или нет, и отдаёт задачу ещё раз. Доставки «ровно один раз» в природе нет. Есть «хотя бы один раз» (at-least-once).

• Повтор с паузой (retry with backoff) — не получилось, пробуем через 1, 5, 30 секунд, а не долбим без остановки.
• Очередь неудачников (dead letter queue) — задача упала десять раз и уходит в отдельный список, который смотрит человек. Иначе она молча пропадёт.
• Таблица исходящих (outbox) — как не потерять событие. «Заказ создан» записывается в базу той же транзакцией, что и сам заказ, а отдельный процесс потом отправляет его дальше. Заказ записан — событие точно уйдёт. Не записан — точно не уйдёт.

10Куб масштабирования и как делают большие

У инженеров есть стандартная модель: три оси, по которым система может расти.

11Расчёт: 30 000 человек одновременно

Это около десятка машин, а не сотни. Без кэша на входе та же нагрузка потребовала бы в семь–десять раз больше копий приложения — вот цена первого рычага.

12Отказы и резервные копии

Всё ломается: диски, сети, хостеры, люди. Вопрос не «сломается ли», а «что будет, когда сломается».

• Единая точка отказа (single point of failure) — деталь, с отказом которой встаёт всё. Архитектор ищет такие детали и либо дублирует их, либо записывает как принятый риск.
• Допустимая потеря данных (RPO) — сколько минут работы можно потерять при аварии. Копия раз в сутки — значит, можно потерять сутки.
• Время восстановления (RTO) — через сколько система снова работает.

Взрослая система начинается с того, что эти две цифры записаны и проверены учением.

Следующие ступени после вывоза копий: восстановление на момент времени (PITR) — база пишет журнал всех изменений, и её можно вернуть на любую минуту, а не только на ночь; и горячая копия (standby) — вторая база на другой машине, которая повторяет главную и подхватывает работу при её отказе.

13Как не упасть целиком

Масштаб — это не только «больше». Это ещё и «чтобы отказ части не стал отказом всего».

• Обратное давление (backpressure). Перегруженная система должна честно отказывать части запросов — «попробуйте через 5 секунд», — а не принимать всё и умирать. Инструмент — лимит запросов (rate limit).
• Пределы времени (timeout). Каждый вызов наружу и в базу — с потолком ожидания. Иначе один зависший сосед вешает всех, кто его ждёт.
• Предохранитель (circuit breaker). Сосед не отвечает — перестаём его дёргать на минуту и сразу отдаём запасной ответ. Как автомат в электрощитке.
• Изоляция поломки. Упал поиск — каталог работает. Упал чат — заказы идут.
• Деградация (graceful degradation). Под перегрузкой система жертвует второстепенным — рекомендациями, счётчиками, — чтобы сохранить главное: оформление заказа.

14Выпуск изменений

Чаще всего систему ломает не нагрузка, а собственное обновление. Поэтому у выпуска своя механика.

• Стенд и бой (staging и production). Стенд — копия системы для проверок. Бой — то, чем пользуются люди. Они должны быть раздельными: иначе эксперимент ломает живое.
• Автосборка (CI). Робот, который на каждое изменение сам запускает проверки: типы, тесты, защитные правила. Её ценность в том, что это проверка, которая не зависит ни от чьего мнения.
• Маленькие шаги и откат (rollback). Чем меньше изменение, тем проще понять, что сломало, и вернуть как было. Способ отката придумывают до выкатки.
• Постепенная выкатка (canary). Новая версия сначала достаётся 1–5 % людей. Если ошибок не прибавилось — всем.
• Рубильник (feature flag). Код выложен, функция выключена. Включают настройкой, без новой выкатки — и так же выключают.
• Проверка на живом устройстве. Тест проверяет то, что придумал автор теста. Телефон в руках проверяет то, что есть на самом деле.

15Приборы: как видеть систему

Систему, которую не видно, нельзя ни чинить, ни растить. Сигналов три вида:

• Метрики (metrics) — цифры во времени: запросов в секунду, доля ошибок, загрузка процессора. Отвечают на вопрос «что происходит».
• Журналы (logs) — запись каждого события. Отвечают на вопрос «что именно случилось с этим запросом».
• Трассировка (tracing) — путь одного запроса по всем слоям с временем на каждом. Отвечает на вопрос «где тормозит».

Задержку смотрят не по среднему, а по «хвосту»: p95 — время, в которое укладываются 95 запросов из 100. Среднее 0,4 секунды может скрывать, что каждый двадцатый человек ждёт пять секунд.

16Деньги

Денежная часть устроена не как остальной код. Её цель — чтобы ошибку было невозможно сделать и невозможно скрыть.

1. Суммы — целым числом копеек. Дробные числа компьютер хранит приближённо: у него 0,1 + 0,2 не равно 0,3. На миллионе операций копейки расползаются.
2. Двойная запись (double-entry ledger). Каждая операция — две строки: откуда ушло и куда пришло. Сумма всех строк всегда ноль. Баланс не хранится числом, которое правят, — он считается из журнала.
3. Журнал только на дозапись. Ошибку исправляют новой, обратной строкой. Стереть или поправить старую нельзя. Так устроены банки.
4. Ключ идемпотентности (idempotency key). Связь плохая, человек нажал «оплатить» дважды. У обоих запросов один и тот же номер операции — сервер видит повтор и не списывает второй раз.
5. Сверка (reconciliation). Каждый день сравнивать свой журнал с выпиской банка или платёжной службы. Сверка существует ровно для одного: поймать разницу между «мы думаем» и «на счёте есть». Сверка своих записей со своими же ничего не ловит.
6. Цепочка с компенсацией (saga). Заказ — это резерв товара, списание денег, уведомление. Они живут в разных системах, одной транзакцией их не обернуть. Поэтому у каждого шага есть обратный: не прошло списание — снять резерв.
7. Удержание (escrow). Деньги покупателя не уходят продавцу сразу, а лежат до подтверждения получения.
8. Чарджбэк (chargeback). Банк покупателя может вернуть платёж по жалобе клиента — через недели после сделки. Это должен быть описанный процесс, а не сюрприз.

17Защита

Защита — не отдельный этап в конце, а привычка задавать вопрос «а что, если это сделает злоумышленник?» к каждой функции.

• Модель угроз (threat model) — до кода: кто нападает, чего хочет, каким путём, чем закрыто. Дешевле, чем разбор после взлома.
• Вход и права — разные вещи. Вход (authentication) — «кто ты». Права (authorization) — «что тебе можно». Самая частая дыра в любых сервисах: человек вошёл честно, а потом открыл чужой заказ, подставив чужой номер.
• Минимальные права (least privilege). Каждый человек и каждая программа получают ровно столько доступа, сколько нужно для работы.
• Не доверяй входу. Всё, что пришло снаружи — форма, файл, ответ партнёра, уведомление от платёжной службы (webhook), — проверяется, как будто его прислал враг.
• Секреты — ключи и пароли — не лежат в коде и не попадают в журналы.
• Личные данные (PII): собирать меньше, хранить зашифрованно, в журналы не писать.
• «Четыре глаза» на деньги: один создаёт выплату, другой подтверждает.
• Лимиты на всё, что стоит денег: СМС, попытки входа, тяжёлые запросы.
• Второй фактор (2FA) для сотрудников и админки.
• Цепочка поставки (supply chain). В продукте сотни чужих библиотек; уязвимость в любой — твоя уязвимость. Их проверяют автоматически при сборке.
• Мошенничество — это не взлом. Накрутки, фальшивые заказы, сговор покупателя с продавцом идут через честные двери. Против них работают правила и наблюдение, а не замки.

18Страны

Правило одно: страна должна быть настройкой, а не кодом. Настройкой становятся:

19Из чего он состоит

Твой маркетплейс — модульный монолит: один код и одна выкатка, а внутри — модули с границами (корзина, заказы, платежи, доставка, промо). Для команды твоего размера это мировой стандарт. По документам

Приложение, база, очереди и файлы работают на одной машине. По документам

20Что сделано по-взрослому

Это не комплимент, а опора: на этом можно строить, и этого не надо переделывать. По документам

21Чего нет — в порядке «что ударит раньше»

Факты — из кода и документов проекта, порядок — мой. По документам Моя позиция

Про поиск отдельно: каталог сейчас около 9 700 товаров, две недели назад было 344. До границы поиска в 100 000 ещё на порядок, но скорость роста каталога — сама по себе цифра, за которой стоит следить. Измерено 14.11

22Панель реальности: снимок 14.11.2026

Шесть цифр, ни одна из которых не мнение нейросети. Это первый снимок; дальше — раз в неделю. Одна цифра из шести пока не снята.

Что говорят цифры

• Продукт ожил на этой неделе. Показы товаров: 08.11 — 44 в день, 11.11 — 335, 12.11 — 2 157, 13.11 — 8 396. За неделю: 11 189 показов → 244 клика → 333 просмотра карточки → 11 заявок. Учётных записей 75, из них 37 появились за семь дней. Что именно произошло 12–13.11, из цифр не видно.
• Масштаб — десятки людей. До «десятков тысяч одновременно» три порядка. Диск сервера занят на 39 %, копия базы весит 24 МБ. Нагрузка сейчас не ограничивает ничего.
• На одну удалённую строку кода — пять с половиной новых. Плюс за ту же неделю 13,5 тысячи строк тестов и 12,3 тысячи строк документов.

23Главное противоречие и порядок шагов

Код опережает бизнес. Написаны банковский учёт, удержание, возвраты, споры — и не принят ни один настоящий платёж. Типовой провал здесь называется «строю собор до первой службы». Риск не в том, что система не выдержит 300 000 заказов. Риск в том, что первые 300 покажут: деньги ходят иначе, логист отвечает иначе, покупатель хочет иначе — и часть собора придётся перекладывать.

Лестница роста: что делать на какой цифре

Ближайшие шаги

1. Вывоз копий за пределы сервера. К росту отношения не имеет, но стоит первым: без него всё остальное строится на песке.
2. Вернуть автосборку. Это счёт, а не разработка.
3. Сеть доставки перед витриной и картинками. Код к этому готов. Сначала проверить, как выбранная сеть работает для покупателей в России.
4. База на отдельной машине с горячей копией. И рост, и страховка. Срок — до включения оплаты.
5. Профиль одного запроса: куда уходит процессор. Триггер не нужен — это дёшево.
6. Дальше — только по триггерам из таблицы выше.

Чего делать не надо: дробить монолит на службы, ставить тяжёлую систему управления контейнерами ради пяти машин, делить базу.

24Как устроена твоя фабрика

Весь код пишут нейросети. Чтобы это работало, ты построил конвейер: у каждой задачи одна и та же дорога.

Пять принципов, на которых это держится:

• Три уровня риска. Правка текста не проходит тот же путь, что возврат денег. Уровень назначается до начала.
• Чистый контекст у проверяющего. Он не видит рассуждений автора и не заражается ими. Нейросеть, которой показали вывод, склонна его подтвердить.
• Сначала тест, потом код. Тест — это записанное требование, которое можно запустить.
• Память — в файлах. У нейросети нет памяти между разговорами. Всё, что должно пережить сессию, записывается.
• Один хозяин у задачи. Две нейросети не правят одно и то же одновременно.

25Что в ней работает и что нет

Цифры собраны 14.11.2026 по истории кода и файлам офиса.

Пять причин, по порядку тяжести

1. Нет обратной связи от реальности. Почти все источники правды в контуре — мнение нейросети. Она описывает ожидаемое поведение продукта, а не фактическое, и отличить одно от другого нечем.
2. Фабрика работает не на узкое место. Запуск денег держат договор с платёжной службой, ответ юриста и модель оплаты доставки. Ни одно из трёх — не код. Когда узкое место снаружи, а производство идёт внутри, растёт не продукт, а цена его содержания.
3. Добавлять умеют все, убирать — никто. Каждый проверяющий получает вопрос «чего не хватает?». Нейросеть на него всегда находит ответ. Вопрос «что лишнее?» долго не задавал никто.
4. Память переросла голову. Файлы памяти выросли до мегабайт. Читать их целиком невозможно — значит, читают кусками и не говорят об этом.
5. Правила только копятся. После каждого сбоя появляется правило. Ни срока, ни цифры для отмены у правил нет.

26Свойства нейросети, которые надо знать

Это не лечится формулировкой запроса. Это свойства инструмента — их обходят устройством работы.

27Как ставить задачу

Сначала честно: твои запросы — не первая причина проблем. Размытую диктовку система исправляет сама. Но три привычки стоят дорого.

• «Без ограничений», «сколько нужно». Для модели это команда «максимум объёма». Нет точки остановки — будет больше помощников, файлов и страниц.
• Нет слов «не делать» и «готово». Пустоту нейросеть заполняет сама, и всегда в сторону «больше».
• Противоречивые сигналы. «Быстрее», «меньше кода» и «максимально надёжно» в одной задаче модель примиряет единственным способом — добавляет процесс.

Диктовать можно так же свободно. Но в конце — пять строк:

Результат:     что я хочу держать в руках.
Зачем:         какое решение я приму на основе этого.
Готово, когда: признак, по которому остановиться.
Не делать:     что вне задачи.
Бюджет:        объём ответа, время, сколько помощников.

Что у тебя сильное — сохрани. Ты разрешаешь спорить и требуешь честности. Записываешь решения с датой. Меняешь процесс в день сбоя. Так работают немногие.

28Десять вопросов и семь правил

Вопросы, которые профессионал задаёт к любой задаче

Их можно задавать нейросети дословно. Ответ «не знаю» или «не измерено» — нормальный ответ, с ним можно работать. Плохой ответ — уверенный и без цифры.

1. Какую цифру пользователя или денег это двигает?Нет цифры — задача ждёт. Это и есть тормоз.
2. Что здесь сломается первым и при какой цифре?Потолок должен быть назван числом.
3. Что увидит человек, если эта часть упадёт?Изоляция и деградация.
4. Что будет, если запрос придёт дважды?Идемпотентность.
5. Где здесь состояние и кто его хозяин?Одна правда — в одном месте.
6. Что здесь растёт без потолка?Таблицы, журналы, очереди, файлы.
7. Каким прибором я увижу, что это работает в бою?Не «тесты зелёные», а цифра с живой системы.
8. Как это откатить?Придумывается до выкатки.
9. Что здесь можно не делать?Лучшая деталь — отсутствующая.
10. Что привязывает нас к одной стране или одному поставщику?Цена будущего выхода.

Семь правил стройки с нейросетями

1. Панель реальности раз в неделю. Шесть цифр на одной странице, ни одна — не мнение нейросети.
2. Автосборка всегда зелёная. Красная автосборка — авария, а не фон.
3. Живой телефон перед каждым выпуском. Два устройства, одно — в России.
4. К каждой задаче — строка «какую цифру двигает».
5. Потолок на обязательное чтение. Закрытое — в архив. Нейросеть должна успевать прочитать свои правила целиком.
6. Правило — только с цифрой и сроком. Одно новое правило — одно старое на выход.
7. Одна проверка без нейросети в каждой задаче: запуск, замер, телефон или запись из боевого журнала.

Чего не трогать: денежное ядро; проверку постановки до кода; проверку «сломай» на деньгах, входе и личных данных. У них единственных доказанная отдача.

29Словарь

Русское слово, английский термин, объяснение в одну строку. Начни печатать — список сузится.

30Что читать дальше

• Мартин Клеппман, «Высоконагруженные приложения» (Designing Data-Intensive Applications). Главная книга о данных: базы, копии, очереди, согласованность. Читать медленно, первую часть — обязательно.
• Google, «Site Reliability Engineering». Откуда взялись целевые уровни, бюджет ошибок и дежурство. Есть в открытом доступе.
• Майкл Нейгард, «Release It!». Истории аварий и приёмы против них: пределы времени, предохранители, изоляция.
• Мартин Эбботт, Майкл Фишер, «The Art of Scalability». Откуда куб масштабирования.

Не читай всё подряд. Бери главу под вопрос, который стоит на этой неделе.