Проектирование распределённых систем

С чего начинается проектирование системы: не с выбора технологий, а с требований и порядков величин. Модуль вводит рамку — функциональные и нефункциональные требования, оценка нагрузки и объёма данных «на салфетке» — и показывает, что дизайн системы это последовательность решений с ценой, а не схема из прямоугольников.

1. Что такое проектирование системПроектирование системы — это не схема из прямоугольников и не список технологий, а последовательность решений, у каждого из которых есть цена. Урок вводит рамку: система описывается требованиями, из требований следуют ограничения, а из ограничений — выбор компонентов, за который платят задержкой, деньгами или сложностью эксплуатации.
2. Требования и оценка нагрузкиАрхитектуру определяют не функции, а нефункциональные требования: сколько запросов в секунду, какая допустимая задержка, сколько данных и с какой скоростью они растут, что происходит при отказе. Урок показывает, как за несколько минут оценить порядок величины и почему без этой оценки выбор между решениями превращается в вопрос вкуса.

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

1. Масштабируемость и узкое местоСистема масштабируется не «вообще», а до своего узкого места: одна очередь, один узел или один общий ресурс определяет потолок для всей цепочки. Урок показывает, как искать узкое место по слоям, почему добавление ресурсов мимо него ничего не даёт и чем отличается рост вверх от роста вширь на каждом слое.
2. Доступность, избыточность и переключение на резервДоступность измеряют долей времени, когда система отвечает, и девятки в этой доле стоят разных денег: от 99% до 99,99% путь не количественный, а качественный. Урок разбирает, как из доступности компонентов складывается доступность системы, что даёт избыточность и почему переключение на резерв само по себе источник отказов.
3. Надёжность: система отвечает правильноДоступность говорит, что система ответила, надёжность — что ответила верно и не потеряла данные. Урок разводит два свойства, вводит наработку на отказ и время восстановления как разные рычаги и показывает, почему идемпотентность операции превращает повтор из угрозы в штатный механизм восстановления.
4. Единая точка отказа и радиус пораженияЕдиная точка отказа — компонент, падение которого останавливает систему целиком, и он почти никогда не тот, на который показывает схема. Урок показывает, как искать такие точки через анализ зависимостей, чем скрытая общая зависимость опаснее явной и как ограничивают радиус поражения, когда убрать точку отказа нельзя.
5. Задержка, пропускная способность и полосаТри величины, которые постоянно путают: задержка — время одного запроса, пропускная способность — сколько запросов в единицу времени, полоса — сколько данных проходит по каналу. Урок показывает, почему они оптимизируются разными средствами и часто друг другу противоречат, и почему измеряют не среднее, а высокие процентили.
6. Теорема CAP: поведение при разрыве сетиТеорема CAP описывает не свойства продукта, а поведение системы в момент разрыва сети: когда узлы не видят друг друга, приходится выбирать между отказом в ответе и ответом возможно устаревшими данными. Урок разбирает точную формулировку, показывает, почему «выбери два из трёх» вводит в заблуждение, и вводит уточнение о цене согласованности в отсутствие разрыва.
7. Модели согласованности как контракт чтенияСогласованность — не переключатель «строгая или итоговая», а спектр контрактов: что именно вы увидите, прочитав данные после записи, своей или чужой. Урок разбирает линеаризуемость, причинную согласованность, чтение своих записей и монотонность как разные обещания системы и показывает, какое из них требует какой координации.
8. Согласованное хешированиеРаскладка ключей по узлам через остаток от деления ломается при добавлении узла: переезжает почти всё. Согласованное хеширование строит кольцо, где смена состава затрагивает лишь долю ключей. Урок разбирает механизм, роль виртуальных узлов против перекоса и где приём применяется — в кэшах, шардах и маршрутизации.

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

1. Слои сети и адресацияМодель OSI полезна не как список из семи пунктов, а как способ ответить, на каком уровне сломалось: не резолвится имя, не устанавливается соединение или сервер вернул ошибку. Урок разбирает слои через путь одного запроса и показывает роль IP-адреса и маршрутизации в том, как пакет находит машину.
2. TCP против UDP: гарантии против задержкиTCP устанавливает соединение, подтверждает доставку и восстанавливает порядок; UDP отправляет и забывает. Урок показывает, чем именно платит TCP — рукопожатием, повторами и блокировкой очереди при потере, — и почему для голоса, видео и телеметрии осознанно выбирают протокол без гарантий.
3. Семантика HTTP и защищённое соединениеHTTP задаёт не только формат сообщения, но и контракт: какие методы безопасны, какие можно повторять, что означают классы кодов ответа. Урок разбирает эту семантику, влияние версий протокола на число соединений и задержку, и что добавляет TLS — шифрование, подтверждение подлинности и цену рукопожатия.
4. Разрешение имён и кэш DNSDNS превращает имя в адрес через иерархию серверов и несколько уровней кэша, и именно кэш делает его источником сюрпризов: запись изменена, а часть клиентов ещё ходит на старый адрес. Урок разбирает путь разрешения, роль времени жизни записи и почему DNS плохо подходит для быстрого переключения трафика.
5. Прямой и обратный проксиПрямой прокси представляет клиента перед интернетом, обратный — сервис перед клиентами, и от того, на чьей стороне стоит посредник, зависит, что он может: терминировать TLS, кэшировать ответы, ограничивать частоту запросов, скрывать топологию. Урок разводит две роли и показывает, где обратный прокси граничит с балансировщиком и шлюзом API.
6. Контрольные суммы и целостность данныхДанные портятся не только при передаче, но и при хранении, и обнаружить это можно только сравнением с контрольной суммой. Урок разбирает, как считают и где проверяют контрольные суммы, чем проверка целостности отличается от проверки подлинности и почему в распределённом хранилище без неё тихое повреждение остаётся незамеченным.

Как запрос находит один из многих одинаковых экземпляров сервиса: балансировщик и проверки здоровья, алгоритмы раскладки нагрузки и распределение трафика ещё до соединения — через DNS и маршрутизацию. Модуль показывает, что балансировщик решает не только «куда», но и «что делать, когда экземпляр нездоров».

1. Балансировщик и проверки здоровьяБалансировщик принимает запросы вместо сервиса и раскладывает их по экземплярам, но главная его работа — вовремя убрать из ротации тот, который отвечает неправильно. Урок разбирает распределение на транспортном и прикладном уровнях, устройство проверок здоровья и почему слишком грубая проверка выводит из ротации всё сразу.
2. Алгоритмы раскладки нагрузкиКруговой перебор честен только при одинаковых запросах: один тяжёлый запрос на экземпляр делает раскладку неравномерной, даже когда счётчик ровный. Урок сравнивает круговой перебор, наименьшее число соединений, взвешенные варианты и хеш по ключу и показывает, какой профиль нагрузки ломает каждый из них.
3. Распределение трафика до соединенияЧасть трафика распределяют раньше, чем клиент установил соединение: DNS отдаёт разным клиентам разные адреса, маршрутизация на общий адрес ведёт запрос в ближайшую точку присутствия. Урок разбирает оба механизма, их применение для распределения по регионам и почему кэш DNS делает такой способ медленным для аварийного переключения.

Интерфейс сервиса — это обещание, которое дорого менять: стиль взаимодействия, формат сообщения, поведение при повторе запроса, защита от перегрузки и общая точка входа для клиентов. Модуль разбирает, как выбирают стиль API под задачу и какие свойства контракта определяют устойчивость системы, а не удобство разработчика.

1. API как контрактОпубликованный интерфейс перестаёт принадлежать команде: его нельзя поменять, не сломав неизвестных клиентов. Урок вводит API как обещание — какие поля обязательны, что означает ошибка, что гарантируется при повторе — и показывает, почему совместимость определяет темп развития системы сильнее, чем выбор технологии.
2. Стили взаимодействия и выбор между нимиРесурсный интерфейс, вызов удалённой процедуры, запрос по графу и потоковый обмен решают разные задачи и по-разному ведут себя при слабой сети, множестве клиентов и высокой частоте вызовов. Урок сравнивает стили по числу обращений, объёму передаваемого и жёсткости контракта и даёт критерий выбора под профиль клиента.
3. Проектирование ресурсного APIРесурсный интерфейс держится на дисциплине: ресурсы вместо действий, честные коды ответа, предсказуемая пагинация и явная стратегия версий. Урок разбирает эти решения и показывает, как выбор способа пагинации и правил версионирования определяет поведение при росте объёма данных и числа клиентов.
4. Бинарные контракты и схема сообщенияКогда сервисы общаются друг с другом сотни тысяч раз в секунду, текстовый формат становится заметной статьёй расходов. Урок разбирает контракт со схемой и бинарной сериализацией: генерацию кода, правила совместимого изменения схемы, потоковые вызовы — и почему такой контракт удобен внутри системы и неудобен на её границе.
5. Запрос по графу данныхКлиент, которому нужны части пяти ресурсов, делает пять запросов или получает лишнее. Запрос по графу переносит выбор полей на клиента и решает эту проблему, но переносит на сервер и стоимость запроса. Урок разбирает механизм, задачу связанных запросов к хранилищу и способы ограничить сложность запроса.
6. Идемпотентность и безопасный повторВ сети ответ теряется чаще, чем запрос, поэтому клиент повторяет операцию, не зная, выполнилась ли она. Урок показывает, что идемпотентность — это свойство, которое проектируют, а не наследуют от метода: ключ идемпотентности, хранение результата, окно дедупликации, и почему без неё повтор превращается в двойное списание.
7. Ограничение частоты запросовОграничитель защищает не клиента, а систему: он превращает перегрузку в предсказуемый отказ вместо каскадной деградации. Урок сравнивает счётчик в фиксированном окне, скользящее окно и корзину токенов по поведению на границе интервала и разбирает, где ограничитель стоит и как хранит состояние при нескольких экземплярах.
8. Шлюз API как точка входаШлюз собирает в одном месте то, что иначе дублируется в каждом сервисе: маршрутизацию, проверку токена, ограничение частоты, агрегацию ответов. Урок разбирает его роль в топологии, отличие от обратного прокси и балансировщика и цену — новая единая точка отказа и соблазн положить в шлюз бизнес-логику.
9. Identity в масштабируемой системеСерверная сессия привязывает пользователя к конкретной машине и мешает горизонтальному росту; самодостаточный токен снимает привязку, но его нельзя мгновенно отозвать. Урок разбирает этот компромисс на уровне топологии: где проверяется удостоверение, что происходит при отзыве и как единый вход меняет картину отказов.

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

1. Синхронный вызов против асинхронного сообщенияСинхронный вызов связывает сервисы во времени: вызывающий ждёт, и медленный или упавший сосед становится его проблемой. Асинхронное сообщение разрывает эту связь ценой отложенного результата. Урок показывает, как выбор между ними меняет картину отказов и где попытка сделать всё асинхронным усложняет систему без выигрыша.
2. Очереди сообщенийОчередь — это буфер между скоростью поступления работы и скоростью её обработки: пик всасывается в очередь, потребители разбирают её в своём темпе. Урок разбирает механизм подтверждения обработки, конкурирующих потребителей и порядок сообщений, и показывает, почему растущая очередь — это симптом, а не решение.
3. Публикация с подпискойОчередь доставляет сообщение одному потребителю, публикация с подпиской — всем заинтересованным, и это меняет способ развития системы: нового подписчика добавляют, не трогая издателя. Урок разбирает разветвление доставки, роль темы и подписки и цену — издатель перестаёт знать, кто и как обработал событие.
4. Гарантии доставки и идемпотентный потребительСеть теряет подтверждения, поэтому доставка бывает не более одного раза или не менее одного раза, а «ровно один раз» достигается не протоколом, а идемпотентностью потребителя. Урок разбирает, где именно теряется сообщение или возникает дубль, и как дедупликация по ключу превращает повтор в безопасную операцию.
5. Очередь необработанных сообщенийСообщение, которое не удаётся обработать, при бесконечных повторах блокирует очередь и выжигает ресурсы. Урок разбирает отвод таких сообщений в отдельную очередь, политику повторов с нарастающей паузой и почему очередь необработанных сообщений без разбора её содержимого превращается в свалку.
6. Поток изменений из базы данныхЧтобы другие системы узнавали об изменениях, приложение может публиковать события само — и рассинхронизироваться с базой. Захват изменений читает журнал транзакций и превращает факт коммита в поток событий. Урок разбирает механизм, его преимущество перед двойной записью и цену — связь потребителей со схемой хранилища.
7. Обратные вызовы по HTTPОбратный вызов переворачивает направление: не клиент опрашивает сервис, а сервис вызывает клиента при событии. Урок разбирает, что делает такой вызов надёжным — подпись запроса, повторы с паузой, идемпотентность приёмника — и почему получатель обязан отвечать быстро и обрабатывать событие отдельно.
8. Длинный опрос и поток событий от сервераКогда обновление нужно доставить клиенту быстрее, чем он спросит, соединение держат открытым. Урок разбирает два односторонних способа: длинный опрос, где сервер не отвечает до появления события, и поток событий от сервера поверх обычного HTTP с автоматическим переподключением — и цену обоих в открытых соединениях.
9. Двусторонние соединенияВеб-сокет превращает HTTP-соединение в двусторонний канал, где обе стороны шлют сообщения без нового запроса. Урок разбирает переход по рукопожатию, отличие от одностороннего потока событий и системную цену: соединение делает сервер состояние-зависимым, что меняет требования к балансировке и выкладке.
10. Прямое соединение между клиентамиДля голоса и видео путь через сервер добавляет задержку, которой можно избежать: клиенты соединяются напрямую. Урок разбирает роль сервера согласования и обхода трансляции адресов, почему прямое соединение удаётся не всегда и в каких случаях приходится возвращать трафик на ретранслятор.

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

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

Хранилище выбирают не по популярности, а по модели доступа к данным: какие запросы должны быть быстрыми, что можно потерять, как данные растут. Модуль разбирает семейства хранилищ и их профили, гарантии транзакций и сохранности записи, а также две структуры на диске, из которых следует, что быстрее — чтение или запись.

1. Как выбирают хранилищеВопрос не «реляционная база или нереляционная», а какой запрос должен выполняться за миллисекунды, как данные связаны и что случится при потере последней записи. Урок вводит критерий выбора по модели доступа и показывает, почему сравнение семейств хранилищ без профиля нагрузки не даёт ответа.
2. Реляционная модель и её гарантииРеляционная база даёт то, что дорого построить самому: схему, ограничения целостности, транзакции и произвольные соединения таблиц. Урок разбирает, за счёт чего это работает и где начинаются пределы — при связывании больших объёмов и при попытке распределить данные по узлам.
3. Хранилища ключ-значениеСамая простая модель: доступ только по ключу, зато предсказуемо быстрый и легко распределяемый. Урок разбирает, что даёт отказ от произвольных запросов, где такое хранилище незаменимо — сессии, счётчики, кэш, — и почему в момент, когда понадобился поиск по значению, модель перестаёт работать.
4. Документные хранилищаДокумент хранит агрегат целиком, поэтому чтение сущности не требует соединений, а схема может меняться от записи к записи. Урок разбирает, какой профиль доступа это выигрывает, чем платят за отсутствие схемы и почему связи между документами возвращают задачу соединения в код приложения.
5. Хранилища широких колонокМодель, рассчитанная на очень большой объём записи и распределение по многим узлам: данные раскладывают по ключу разбиения, а запросы проектируют заранее. Урок разбирает, почему здесь схема следует за запросом, а не наоборот, и какой ценой достигается линейный рост по узлам.
6. Графовые хранилищаКогда ценность данных в связях, а не в записях, обход на несколько шагов в реляционной модели превращается в каскад соединений. Урок разбирает, как графовое хранилище делает связь такой же сущностью, как узел, и почему выигрыш появляется только на запросах переменной глубины.
7. Хранилища временных рядовМетрики и телеметрия имеют особый профиль: запись почти всегда добавление в конец, чтение — агрегат по интервалу, старые данные теряют ценность. Урок разбирает, как из этого профиля следуют сжатие по времени, понижение детализации и автоматическое устаревание данных.
8. Векторные хранилищаПоиск по смыслу вместо совпадения: объекты представляют векторами, а запрос ищет ближайшие. Урок разбирает, почему точный поиск ближайших соседей не масштабируется, что даёт приближённый индекс и какой компромисс между полнотой выдачи и скоростью приходится принять.
9. Полнотекстовый поискПоиск по тексту в базе через сравнение с образцом не масштабируется, потому что задача другая: не найти совпадение, а ранжировать релевантность. Урок разбирает обратный индекс и разбор текста и показывает, почему поисковый индекс — производное хранилище с неизбежным отставанием от источника.
10. Транзакции и гарантии ACIDЧетыре буквы обещают разное: атомарность про всё-или-ничего, согласованность про ограничения схемы, изоляция про видимость чужих изменений, сохранность про переживание отказа. Урок разводит их и показывает, что на практике настраивают именно изоляцию, а цена согласованности в CAP — совсем другая величина.
11. Как база гарантирует сохранность записиПодтверждение записи — это обещание пережить отказ, и держится оно на журнале упреждающей записи: сначала запись в журнал, потом изменение данных. Урок разбирает этот механизм, роль сброса на диск и репликации и почему настройка подтверждения — это выбор между скоростью и допустимым объёмом потери.
12. Сбалансированное дерево против дерева слиянияДве структуры на диске задают профиль движка: сбалансированное дерево обновляет страницу на месте и выигрывает на чтении, дерево слияния пишет последовательно и выигрывает на записи ценой фонового слияния и усиления чтения. Урок разбирает механизм обеих и показывает, почему выбор движка это выбор в пользу чтения или записи.

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

1. Реплики на чтение и отставаниеРеплика снимает нагрузку чтения с основного узла, но приносит отставание: пользователь может не увидеть только что сделанную запись. Урок разбирает механизм репликации, синхронный и асинхронный режимы и приёмы против видимого отставания — чтение своих записей с основного узла и явный бюджет свежести.
2. Пул соединенийСоединение с базой — дорогой и ограниченный ресурс: сотни экземпляров сервиса легко исчерпывают лимит, и база отказывает раньше, чем упирается в процессор. Урок разбирает пул соединений, его размер как производную от параллелизма и почему очередь за соединением проявляется как рост задержки без роста нагрузки.
3. Денормализация и материализованные представленияНормализованная схема экономит место и защищает целостность, но заставляет соединять таблицы на каждом чтении. Урок разбирает перенос этой работы на запись: дублирование полей и предвычисленное представление — и цену, которую платят рассогласованием копий и усложнением обновления.
4. Шардирование и выбор ключаКогда данные не помещаются на узел или запись упирается в один сервер, их разбивают по ключу. Урок показывает, что ключ разбиения — главное решение: он определяет равномерность нагрузки, появление горячих точек и то, какие запросы станут дорогими, потому что затрагивают несколько шардов.
5. Горизонтальное и вертикальное разбиениеТаблицу режут по строкам или по колонкам, и это разные операции с разными выигрышами: разбиение по строкам ограничивает объём сканирования и упрощает удаление старых данных, разбиение по колонкам отделяет редко используемые и тяжёлые поля. Урок разводит их и показывает связь с шардированием.
6. Сжатие данныхСжатие меняет процессорное время на объём: меньше данных на диске означает меньше операций ввода-вывода и больше полезного в кэше страниц. Урок разбирает, где сжатие выигрывает — колоночные форматы, холодные данные, передача по сети — и где проигрывает на нагрузке со случайным доступом.
7. Индекс как компромиссИндекс ускоряет чтение и замедляет запись, занимает место и требует поддержки, поэтому вопрос не «есть ли индекс», а сколько их система может себе позволить. Урок разбирает этот компромисс на уровне системы и показывает, почему лишние индексы на нагрузке с преобладанием записи становятся узким местом.

Где живут файлы, изображения, видео и резервные копии, когда их слишком много для диска одной машины. Модуль разбирает три модели доступа к хранилищу, устройство объектного хранилища, распределённые файловые системы и способ пережить отказ дисков дешевле, чем полными копиями.

1. Блочное, файловое и объектное хранилищеТри модели отличаются тем, что именно вы адресуете: блок на устройстве, путь в дереве каталогов или объект по идентификатору. Урок разбирает, какие свойства следуют из каждой модели — произвольная запись, общий доступ, масштабирование — и почему выбор модели определяет предел роста раньше, чем выбор поставщика.
2. Объектное хранилищеОбъектное хранилище отказывается от дерева каталогов и изменения файла на месте, и именно этот отказ даёт практически неограниченный рост. Урок разбирает плоское пространство имён, метаданные и доступ по HTTP, классы хранения по частоте обращения и согласованность операций записи и чтения.
3. Распределённые файловые системыФайл, который не помещается на одну машину, режут на блоки и раскладывают по узлам, а сведения о том, где что лежит, хранят отдельно. Урок разбирает эту схему, роль узла метаданных как потенциальной единой точки отказа и почему такие системы оптимизированы под последовательное чтение больших файлов.
4. Помехоустойчивое кодирование против репликацииТри копии данных переживают отказ двух дисков, но занимают втрое больше места. Помехоустойчивое кодирование даёт ту же устойчивость при заметно меньших накладных расходах, но восстановление требует чтения многих узлов. Урок разбирает компромисс и показывает, для каких данных выбирают тот или иной способ.

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

1. Рост вверх против роста вширьБолее мощная машина не требует менять код, но упирается в потолок и остаётся одной точкой отказа; больше машин снимает потолок ценой распределённости со всеми её проблемами. Урок разбирает, где проходит граница между подходами и почему вертикальный рост часто правильный первый шаг, а не признак незрелости.
2. Состояние в сервисе или вне егоСервис, помнящий что-то между запросами, привязывает пользователя к конкретной машине — и ломает и балансировку, и выкладку, и восстановление после отказа. Урок разбирает, что именно считается состоянием, куда его выносят и в каких случаях состояние в сервисе осознанно оставляют.
3. Передача по инициативе источника или получателяИсточник может слать данные сам или ждать, пока их запросят, и выбор определяет свежесть, нагрузку и поведение при недоступности одной из сторон. Урок сравнивает подходы на примерах ленты, метрик и уведомлений и показывает, где гибридная схема с уведомлением и последующим запросом снимает недостатки обоих.
4. Конкурентность против параллелизмаКонкурентность — про структуру программы, где несколько задач продвигаются, чередуясь; параллелизм — про одновременное выполнение на нескольких ядрах. Урок разводит понятия и показывает, почему задача, упирающаяся в ожидание ввода-вывода, и задача, упирающаяся в процессор, требуют разных решений на уровне системы.

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

1. Клиент-сервер и разделение на уровниБазовая форма, из которой выросли остальные: инициатор запроса отделён от владельца данных, а между ними появляются уровни представления, логики и хранения. Урок разбирает, что даёт это разделение, почему уровень и физический сервер это разные вещи и где проходит граница ответственности клиента.
2. МонолитМонолит — не стадия развития, а архитектура со своими сильными сторонами: один процесс, одна транзакция, вызов вместо сети, простая отладка. Урок разбирает, где он выигрывает и что именно упирается в потолок при росте — выкладка, время сборки, связанность команд, а не производительность как таковая.
3. МикросервисыМикросервисы покупают независимую выкладку и масштабирование отдельных частей ценой превращения вызова функции в сетевой запрос, который может не дойти. Урок разбирает эту сделку целиком: границы владения данными, отказ от общей транзакции, эксплуатационная цена и признаки, что систему разрезали слишком рано.
4. Событийная архитектураВ событийной системе отправитель сообщает о факте, а не вызывает исполнителя, и потому не знает, кто отреагирует. Урок разбирает эту инверсию зависимости, разницу между уведомлением о событии и передачей состояния и цену — поведение системы перестаёт читаться по одному месту в коде.
5. Хранение событий вместо состоянияВместо текущего значения система хранит последовательность изменений, а состояние получает воспроизведением. Урок разбирает, что это даёт — полную историю, восстановление на любой момент, новые проекции задним числом — и чем платят: миграция схемы событий, снимки, рост журнала и сложность отладки.
6. Разделение моделей чтения и записиЗапись и чтение предъявляют к модели разные требования, и разделение позволяет оптимизировать их независимо. Урок разбирает механизм, синхронизацию моделей и неизбежное отставание представления для чтения и показывает, почему разделение оправдано при большой асимметрии нагрузки, а не по умолчанию.
7. Гексагональная архитектураДомен не должен зависеть от базы, брокера и веб-фреймворка: зависимости разворачивают через порты и адаптеры. Урок разбирает эту инверсию, что она даёт при замене инфраструктуры и тестировании и где буквальное следование схеме превращается в лишние слои без выигрыша.
8. Бессерверные вычисленияМодель, где вы не управляете сервером и платите за вызовы, а не за время работы машины. Урок разбирает, что из этого следует — автоматическое масштабирование, холодный старт, ограничение времени выполнения, отсутствие состояния между вызовами — и какой профиль нагрузки делает такую модель выгодной или разорительной.
9. Обмен между равными узламиВ сети равных узлов нет выделенного сервера: каждый участник одновременно потребитель и источник, и пропускная способность растёт вместе с числом участников. Урок разбирает поиск участника и данных, устойчивость такой сети к отказу узла и почему модель редко подходит для системы с гарантиями и правами доступа.

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

1. Шлюз как единая точка входаКогда сервисов десятки, клиент не должен знать их адреса и повторять у себя проверку токена и ограничение частоты. Урок разбирает шлюз как место, где это собрано, его обязанности и границы и почему шлюз одновременно снимает дублирование и создаёт новую единую точку отказа.
2. Отдельный слой под клиентаМобильному приложению и веб-интерфейсу нужны разные наборы данных, и общий интерфейс неизбежно оказывается компромиссом, плохим для обоих. Урок разбирает выделение отдельного слоя под каждый тип клиента, что это даёт по числу запросов и объёму ответа и во что обходится дублированием логики.
3. Обнаружение сервисовАдреса экземпляров меняются при каждой выкладке и автоматическом масштабировании, и конфигурация со списком адресов устаревает быстрее, чем её обновляют. Урок разбирает реестр сервисов, регистрацию и проверки здоровья, клиентскую и серверную схемы поиска и поведение при недоступности самого реестра.
4. Размыкатель цепиПовторы к упавшему сервису не помогают, а добивают его и заодно исчерпывают потоки вызывающего: отказ распространяется по цепочке. Урок разбирает размыкатель — учёт ошибок, размыкание, пробное полуоткрытое состояние — и его связь с таймаутами, повторами и запасным ответом.
5. Изоляция ресурсов по отсекамОдин медленный сосед способен занять весь пул потоков или соединений, и тогда падает всё, включая не связанные с ним операции. Урок разбирает разделение ресурсов на изолированные отсеки, выбор границы изоляции и цену — часть ресурсов простаивает ради ограничения радиуса поражения.
6. Вспомогательный контейнер и сетка сервисовПовторы, взаимная проверка подлинности, сбор метрик и маршрутизация нужны каждому сервису и потому дублируются на каждом языке. Урок разбирает вынос этой логики в соседний процесс и сетку сервисов как управляемый слой связи, а также цену: лишний сетевой участок, задержка и ещё одна система, которую надо эксплуатировать.
7. Постепенная замена старой системыПереписать систему целиком и выложить одним днём почти всегда провал. Урок разбирает постепенное замещение: перехватчик перед старой системой направляет часть операций в новую реализацию, доля растёт, старый код умирает по частям — и что делает такой переход обратимым на каждом шаге.

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

1. Что меняет распределённостьЛокальный вызов либо выполнился, либо нет; сетевой имеет третий исход — неизвестно. Урок разбирает, какие привычные допущения перестают работать: сеть надёжна, задержка нулевая, полоса бесконечна, топология неизменна, — и показывает, почему именно третий исход порождает большую часть сложности остального модуля.
2. Разрыв сетиПри разрыве сети группа узлов продолжает работать, не видя другую группу, и обе считают себя рабочими. Урок разбирает, почему изнутри невозможно отличить упавший узел от недоступного, какие решения приходится принимать в этот момент и как разрыв связан с выбором между согласованностью и доступностью.
3. Обнаружение отказов и сигналы жизниУзел не сообщает о своей смерти, поэтому его отсутствие приходится выводить из молчания. Урок разбирает периодические сигналы жизни, выбор интервала и порога и цену ошибки в обе стороны: слишком короткий порог объявляет мёртвым живой узел, слишком длинный оставляет систему без реакции.
4. Работа с отказами: таймауты, повторы, деградацияОжидание без ограничения превращает отказ соседа в собственный отказ, а повтор без паузы добивает восстанавливающийся сервис. Урок разбирает набор приёмов — таймаут, повтор с нарастающей паузой и разбросом, запасной ответ, частичная деградация — и как они складываются в предсказуемое поведение под отказом.
5. Расхождение часовЧасы на разных машинах идут по-разному и корректируются скачками, поэтому метка времени одного узла не сравнима с меткой другого. Урок разбирает источники расхождения, что даёт синхронизация по сети и почему построенный на физическом времени порядок событий ошибается именно тогда, когда это дороже всего.
6. Логические часы и порядок событийПорядок в распределённой системе задают не часами, а причинностью: если одно событие могло повлиять на другое, оно должно считаться более ранним. Урок разбирает счётчики, передаваемые вместе с сообщениями, отношение предшествования и почему такой порядок частичный, а не полный.
7. Векторные часы и конкурентные измененияОдного счётчика мало, чтобы отличить «позже» от «одновременно и независимо». Урок разбирает вектор счётчиков по числу узлов, сравнение векторов и обнаружение конкурентных изменений — и что система делает дальше: выбирает последнее по времени, сливает версии или отдаёт конфликт наверх.
8. Выбор ведущего узлаМногие задачи проще, когда решение принимает один узел: он сериализует записи и убирает конфликты. Урок разбирает, как группа выбирает ведущего, что происходит при его недоступности и почему главная опасность не отсутствие ведущего, а появление второго.
9. Консенсус: согласие группы узловКонсенсус — задача договориться об одном значении так, чтобы решение пережило отказы части узлов и не было отменено. Урок разбирает требования к решению, роль большинства и почему при недоступности большинства правильное поведение — отказать, а не продолжить работу.
10. Консенсус через реплицируемый журналПротокол разбивает задачу на понятные части: выбор ведущего, репликация журнала и условия безопасности. Урок разбирает эти части, роль срока полномочий и правило фиксации записи большинством — и показывает, как из этого следует поведение кластера при потере ведущего.
11. Классический протокол консенсусаПротокол, доказавший, что согласие достижимо при отказах узлов, и задавший рамку для всех последующих. Урок разбирает роли участников и две фазы соглашения, почему протокол сложен для реализации и что именно от него унаследовали более практичные схемы.
12. Разделение на две активные половиныПри разрыве сети обе половины кластера могут выбрать своего ведущего и продолжить принимать записи — а после восстановления связи выяснится, что истории разошлись. Урок разбирает механизм этой ситуации, защиту через большинство и ограждающие метки и почему слияние разошедшихся историй в общем случае невозможно.
13. Распределённые блокировкиБлокировка в одном процессе надёжна, потому что владелец и хранитель блокировки живут вместе; в распределённой системе владелец может зависнуть или потерять связь, не освободив её. Урок разбирает срок аренды, продление и ограждающие метки и почему блокировка не заменяет идемпотентность.
14. Протокол сплетенРассылать сведения о составе кластера каждому от каждого не масштабируется. В протоколе сплетен узел передаёт то, что знает, случайным соседям, и знание расходится по системе. Урок разбирает механизм, скорость сходимости и почему такой обмен устойчив к отказам, но даёт только итоговую согласованность.

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

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

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

1. Зачем приближённые структурыНа больших объёмах точный ответ упирается в память: множество из миллиардов элементов не помещается ни в кэш, ни в оперативную память узла. Урок вводит обмен точности на память как осознанное решение и задаёт рамку выбора: какая ошибка допустима, в какую сторону она направлена и что делает её безопасной.
2. Фильтр БлумаСтруктура отвечает на вопрос о принадлежности множеству, занимая биты вместо элементов, и ошибается только в одну сторону: может сказать «возможно есть» про отсутствующий элемент, но никогда не пропустит имеющийся. Урок разбирает механизм, зависимость доли ошибок от размера и почему элемент нельзя удалить.
3. Кукушкин фильтрФильтр, сохраняющий односторонность ошибки, но допускающий удаление: вместо битов он хранит короткие отпечатки и вытесняет их между двумя возможными позициями. Урок разбирает механизм вытеснения, поведение при заполнении и когда возможность удаления оправдывает более сложную структуру.
4. Счётный эскиз частотыХранить счётчик для каждого ключа невозможно, если ключей миллиарды, а знать самые частые нужно. Урок разбирает матрицу счётчиков с несколькими хеш-функциями, оценку частоты по минимуму и направление ошибки — оценка завышена, но не занижена — и почему это подходит для ограничения частоты и поиска популярного.
5. Оценка числа уникальных значенийТочный подсчёт уникальных значений требует хранить их все; оценка укладывается в килобайты. Урок разбирает идею — длина серии нулей в хеше как индикатор мощности множества, — типичную погрешность и главное практическое свойство: такие оценки можно складывать, объединяя результаты разных узлов.
6. Оценка схожести наборовСравнить два больших множества напрямую дорого, а знать степень их пересечения нужно — для дедупликации и поиска похожего. Урок разбирает представление множества набором минимальных хешей и оценку схожести по совпадению этих значений, а также цену компактности в точности оценки.
7. Дерево хешейЧтобы понять, чем отличаются две копии данных, необязательно передавать их целиком: достаточно сравнить корневые хеши и спуститься по расходящимся ветвям. Урок разбирает построение дерева, поиск расхождения за логарифмическое число шагов и применение в сверке реплик и проверке целостности.
8. Список с пропускамиОтсортированный список с несколькими уровнями ссылок даёт логарифмический поиск без балансировки дерева, а уровни выбираются случайно. Урок разбирает структуру, почему вероятностная балансировка даёт нужную сложность в среднем и чем такой список удобнее дерева при конкурентном доступе.
9. Пространственные индексыОбычный индекс не отвечает на запрос «что рядом», потому что близость на плоскости не сводится к порядку по одному ключу. Урок разбирает два подхода: рекурсивное разбиение плоскости на квадранты и группировку объектов охватывающими прямоугольниками — и какой профиль данных подходит каждому.
10. Кодирование координат и разбиение сферыЧтобы искать по координатам обычным индексом, точку превращают в строку, где общий префикс означает близость. Урок разбирает это кодирование, его слабое место на границах ячеек и промышленные схемы разбиения сферы на ячейки, которые дают более равномерные области и удобную иерархию.

Как считают то, что не помещается в один запрос к базе: обработка накопленным объёмом или непрерывным потоком, распределённое вычисление по узлам, перенос данных в аналитическое хранилище и архитектуры, которые пытаются совместить точность батча со свежестью потока.

1. Пакетная обработка против потоковойОдин и тот же результат можно получить, посчитав всё накопленное разом или обрабатывая события по мере поступления. Урок разбирает разницу по задержке, полноте данных, стоимости пересчёта и сложности эксплуатации и даёт критерий: когда свежесть действительно нужна, а когда за неё платят зря.
2. Распределённое вычисление по узламМодель, сделавшая обработку больших объёмов доступной: данные разбивают, обрабатывают независимо на многих узлах, затем сводят результаты по ключу. Урок разбирает этапы, перемешивание как главную статью расходов и перекос по ключу, из-за которого одна задача держит весь расчёт.
3. Потоковые движки: окна и состояниеПоток бесконечен, поэтому агрегат считают в окне, а состояние приходится хранить между событиями. Урок разбирает виды окон, разницу между временем события и временем обработки и что делать с опоздавшими данными — от водяных знаков до пересчёта.
4. Конвейеры переноса и преобразованияДанные редко приходят в аналитическое хранилище в пригодном виде: их извлекают, преобразуют и загружают. Урок разбирает шаги конвейера, различие в порядке преобразования и загрузки и что делает конвейер надёжным — идемпотентность шага, повторный запуск за период, контроль качества данных.
5. Аналитическое хранилищеАналитические запросы сканируют миллионы строк по нескольким колонкам, и хранилище под них устроено иначе, чем база под приложение. Урок разбирает колоночное хранение и схему вокруг фактов и измерений и почему аналитику выносят из рабочей базы, а не добавляют к ней реплику.
6. Озеро данных и гибридный подходОзеро хранит сырые файлы без схемы заранее и потому дешёво принимает всё подряд — и по той же причине легко превращается в свалку. Урок разбирает этот компромисс и гибридный подход, добавляющий поверх файлов таблицы, схему и транзакции.
7. Совмещение точности и свежестиДвухпутевая архитектура даёт быстрый приблизительный ответ из потока и точный из батча, но требует двух реализаций одной логики. Однопутевая оставляет только поток, а пересчёт делает повторным чтением журнала. Урок сравнивает подходы и показывает, чего требует второй от системы хранения событий.

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

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

Распределённую систему нельзя отладить, зайдя на сервер: запрос проходит через десяток сервисов, и понять, где он замедлился, можно только по тому, что система о себе сообщает. Модуль разбирает метрики, логи и трассировку, сквозной идентификатор запроса, оповещения по симптому и то, что видит дежурный в момент инцидента.

1. Три вида телеметрииМетрики отвечают, что происходит, логи — что случилось в конкретном случае, трассировка — где именно во всей цепочке. Урок разводит три вида телеметрии по вопросу, на который каждый отвечает, и показывает разницу между мониторингом заранее известных отказов и наблюдаемостью, позволяющей объяснить незнакомый.
2. Метрики и разметка кодаМетрика — это агрегат, дешёвый в хранении и потому пригодный для непрерывного наблюдения, но теряющий подробности. Урок разбирает основные типы метрик, размерности и взрыв кардинальности при неудачной разметке и почему по среднему времени ответа нельзя судить о том, что чувствуют пользователи.
3. Логи: структура, уровни, сборЛог в свободной форме читает человек, лог со структурой — запрос по полям, и на десятке сервисов работает только второе. Урок разбирает структурированные записи, осмысленные уровни, выборку и удержание, сбор в общее хранилище и цену полного логирования на высокой нагрузке.
4. Распределённая трассировкаЗапрос проходит через несколько сервисов, и суммарная задержка не объясняется метриками ни одного из них. Урок разбирает участок и его вложенность, передачу контекста между сервисами, выборку трасс и то, как трассировка показывает не только медленный участок, но и лишние обращения.
5. Сквозной идентификатор запросаОдин идентификатор, присвоенный на входе и переданный дальше, связывает логи всех сервисов в историю одного запроса — и стоит почти ничего. Урок разбирает, где его порождают, как передают через синхронные вызовы и очереди и почему он полезен даже там, где полноценной трассировки нет.
6. Оповещения по симптомуОповещение о загрузке процессора будит человека, когда пользователям хорошо, и молчит, когда им плохо. Урок разбирает переход к оповещениям по симптомам, заметным пользователю, роль целей уровня обслуживания и бюджета ошибок и почему усталость от ложных срабатываний опаснее отсутствия оповещений.
7. Панели и инструкции дежурногоВ момент инцидента нужен не полный набор графиков, а ответ на вопрос, что сломалось и что делать. Урок разбирает панель, построенную под этот вопрос, инструкцию с проверенными шагами и разбор инцидента без поиска виноватого как способ превратить отказ в изменение системы.

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

1. Защищённое соединение в топологииЗамок в браузере говорит только о канале до балансировщика, а дальше трафик может идти открытым. Урок разбирает, где терминируется защищённое соединение и какие участки остаются незакрытыми, что даёт взаимная проверка подлинности между сервисами и во что обходится шифрование внутреннего трафика.
2. Шифрование данных на храненииШифрование диска защищает от кражи носителя и почти ничего не даёт против доступа через приложение с валидными правами. Урок разводит уровни шифрования — носитель, хранилище, отдельное поле, — разбирает управление ключами и их смену и показывает, какую именно угрозу закрывает каждый уровень.
3. Управление секретамиПароль базы в репозитории или в переменной окружения нельзя ни отозвать быстро, ни проследить, кто его читал. Урок разбирает выдачу секретов по требованию из отдельного хранилища, короткий срок жизни и автоматическую смену и почему возможность отозвать доступ важнее стойкости самого секрета.
4. Доступ на основе ролейПрава, выданные пользователям поимённо, перестают поддаваться проверке уже на сотнях пользователей: роль вводит уровень между человеком и разрешением. Урок разбирает модель, её пределы при потребности в правах на конкретный объект и главный вопрос на уровне системы — где решение принимается и как быстро распространяется отзыв.
5. Корпоративный единый входВ корпоративной продаже вход в приложение принадлежит не вам, а каталогу пользователей клиента. Урок разбирает модель доверия между поставщиком удостоверений и приложением, обмен подписанными утверждениями и что меняется в системе: сопоставление пользователей, выдача прав из атрибутов, поведение при недоступности поставщика.
6. Хранение паролейПароль нельзя хранить так, чтобы его можно было прочитать, и нельзя преобразовывать быстрым алгоритмом: скорость проверки работает на подбор. Урок разбирает необратимое преобразование, соль против готовых таблиц, намеренно дорогие функции и почему параметр стоимости пересматривают со временем.