diff --git a/colloquium/readme.md b/colloquium/readme.md
new file mode 100644
index 0000000..1559a3b
--- /dev/null
+++ b/colloquium/readme.md
@@ -0,0 +1,113 @@
+# Коллоквиум
+
+Коллоквиум по распределённым системам пройдёт **23–25 октября 2026 года онлайн**. Расписание и способ записи уточняются — добавим их позже.
+
+- [Формат и подготовка](#формат-и-подготовка)
+- [Оценивание](#оценивание)
+- [Если не получается прийти](#если-не-получается-прийти)
+- [Примеры вопросов](#примеры-вопросов)
+- [Примеры задач](#примеры-задач)
+
+## Формат и подготовка
+
+Коллоквиум состоит из двух частей: вопроса по материалам курса и задачи. Обе части охватывают материалы лекций и семинаров **недель 1–7**. За каждую часть можно получить до **4 баллов**, ещё до **2 баллов** — за усложнение задачи.
+
+За **30 минут** до назначенного времени вы получите в Telegram конкретный вопрос с указанием того, что нужно раскрыть в ответе. Во время подготовки можно пользоваться материалами курса, интернетом и LLM.
+
+Вопрос проверяет понимание основных понятий, механизмов и компромиссов: может потребоваться объяснить принцип работы, сравнить подходы или разобрать небольшой пример. Ориентир для ответа вместе с уточнениями преподавателя — **3–4 минуты**. Уточнения остаются в пределах выданного вопроса. Во время ответа на первую часть можно пользоваться своими краткими заметками; объяснять ответ и отвечать на уточнения нужно самостоятельно.
+
+Условие задачи вы получите непосредственно на защите, без предварительной подготовки. Нужно предложить решение, объяснить его и разобрать указанные ситуации. Ориентир для основной части — **6–7 минут**, включая чтение, обдумывание и уточнения. Достаточно схемы, последовательности действий или короткого псевдокода; нужно объяснить, что хранят участники и как обрабатывают сообщения.
+
+Полные банки вопросов и задач не публикуются. Ниже приведены [примеры вопросов](#примеры-вопросов) и [примеры задач](#примеры-задач), которые показывают формат и ожидаемую глубину ответа, но не исчерпывают темы коллоквиума.
+
+В назначенное время подключитесь по указанной ссылке **со включённой камерой**. На всю защиту выделено **15 минут**, включая переходы между частями. Указанные времена — примерные ориентиры: время между частями распределяется в пределах общего лимита. Основную часть задачи можно продолжать до конца защиты; превышение ориентировочных 6–7 минут само по себе не снижает оценку. Во время защиты пользоваться LLM нельзя: отвечать на вопросы и рассуждать нужно самостоятельно.
+
+## Оценивание
+
+За подготовленный вопрос и основную часть задачи выставляются целые оценки от 0 до 4:
+
+| Балл | Подготовленный вопрос | Основная задача |
+| --- | --- | --- |
+| 0 | Нет содержательного ответа или понимание не продемонстрировано. | Нет содержательного продвижения к решению. |
+| 1 | Есть отдельные правильные факты, но нет связного объяснения. | Есть отдельные правильные идеи, но они не складываются в решение. |
+| 2 | Основная идея понятна, но есть существенные пробелы или ошибки. | Предложен разумный подход, но решение не выполняет одно из основных требований. |
+| 3 | Ответ в основном правильный, но существенный аспект раскрыт недостаточно. | Решение в основном корректно, но остаётся пробел в требуемом разборе или обосновании. |
+| 4 | Существенные аспекты раскрыты, студент объясняет их и отвечает на уточнения. | Основные требования выполнены, предусмотренные ситуации разобраны, решения обоснованы. |
+
+Для полного ответа нужно раскрыть перечисленные в вопросе или задаче аспекты, объяснить механизмы и разобрать все указанные примеры и ситуации. Простого перечисления терминов или названий технологий недостаточно. Каждая часть оценивается целиком; отдельные баллы за подпункты не начисляются. Самостоятельно исправленная оговорка сама по себе не снижает оценку.
+
+**Если за обе части получено по 4 балла и осталось время, проверяющий сразу даёт усложнение задачи.** Уровни усложнения последовательны: **0 баллов**, если первый уровень не выполнен, **1 балл** — за выполненный первый уровень, **2 балла** — за выполненные оба уровня. Конкретные требования приведены в [примерах задач](#примеры-задач).
+
+Ориентир для обоих уровней вместе — **4–5 минут**, включая чтение, обдумывание и уточнения. Это не гарантированное время: на усложнения используется остаток общего времени защиты. На первом уровне достаточно одного изменения решения с объяснением. На втором нужно разобрать предложенную ситуацию или схему, показать её ограничение и обосновать исправление. Новые условия дополняют или явно изменяют предыдущие.
+
+Итоговая оценка — сумма двух основных оценок и баллов за выполненные уровни усложнения. Если времени на усложнение не осталось, итог определяется двумя основными оценками и не превышает **8 баллов**. Максимум с усложнениями — **10 баллов**.
+
+Вес коллоквиума в оценке за курс — **0,2**. Подробнее — в [правилах оценивания курса](https://distsys.ru/course/hse-2026/src/branch/main/README.md).
+
+## Если не получается прийти
+
+Если вы не подключитесь в назначенное время, за коллоквиум выставляется 0. Заранее проверьте, что сможете прийти и вас не будут отвлекать.
+
+Если не можете прийти по уважительной причине, предупредите преподавателей курса. Если вы пропустите коллоквиум без предупреждения, вам могут отказать в досдаче.
+
+## Примеры вопросов
+
+### Пример 1. Производительность
+
+Чем задержка отличается от пропускной способности? Почему средней задержки недостаточно для оценки сервиса? Что означает p99 времени ответа, равный 200 мс? Приведите пример решения, которое повышает пропускную способность, но увеличивает время ожидания отдельного запроса.
+
+### Пример 2. JSON и Protocol Buffers
+
+Сравните JSON и Protocol Buffers по представлению данных, роли схемы и удобству разработки и диагностики. Можно ли по меньшему размеру сериализованного сообщения сделать вывод, что клиент быстрее получит ответ? Какие ещё затраты нужно учитывать? Приведите ситуацию, в которой вы выбрали бы каждый вариант.
+
+### Пример 3. Общий порядок доставки
+
+Почему репликам сервиса бронирования может понадобиться одинаковый порядок обработки конкурентных заявок? Объясните реализацию Total Order через секвенсор и одно её ограничение. Гарантирует ли само свойство Total Order причинный порядок? Рассмотрите два сообщения, последовательно отправленные одним процессом: могут ли все получатели доставить их в обратном порядке?
+
+## Примеры задач
+
+### Пример 1. Два сервиса обрабатывают события
+
+#### Основная часть — до 4 баллов
+
+Сервис заказов публикует события о создании и изменении заказов. У сервиса уведомлений и сервиса аналитики по несколько обработчиков. Каждый сервис должен обработать все события, распределяя работу между своими обработчиками. События уже надёжно приняты брокером. Обработчики могут аварийно завершаться; после сбоя обработку продолжает другой или перезапущенный обработчик. Повторная обработка одного события безопасна. Иногда аналитика обрабатывает события медленнее, чем они поступают. В основной части места в брокере достаточно.
+
+Предложите схему очередей или подписок и выберите момент подтверждения обработки. Разберите два случая: обработчик получил событие, но завершился до начала обработки; обработал событие, но завершился до отправки подтверждения. Объясните, что происходит с накоплением событий и обработкой уведомлений при замедлении аналитики.
+
+#### Первый уровень усложнения — 1 дополнительный балл
+
+Далее рассмотрим обработку событий внутри одного из сервисов. При каждой попытке обработать одно из событий обработчик аварийно завершается. Брокер умеет надёжно перемещать событие в отдельную очередь для разбора. Предложите правило ограничения числа автоматических попыток. Объясните, где и когда учитывать попытку, чтобы правило работало и при падении обработчика, а остальные события продолжали обрабатываться.
+
+**Критерий выполнения:** Обосновано, что правило ограничивает число автоматических попыток даже при падениях обработчика, сохраняет событие для разбора и позволяет продолжать обработку остальных.
+
+#### Второй уровень усложнения — 2 дополнительных балла за оба уровня
+
+Теперь добавим требование к порядку обработки. Для каждого заказа события пронумерованы последовательно, начиная с 1. Их нужно применять без пропусков, в порядке номеров. Задержка одного заказа не должна останавливать обработку других заказов. Предлагается схема: отправив проблемное событие на разбор, обработчик продвигает номер последнего обработанного события, как после успеха, и продолжает работу. Доступно надёжное хранилище ожидающих событий.
+
+Постройте контрпример к этой схеме и предложите исправленную схему: какое состояние хранить и как обрабатывать события. Объясните, что происходит с последующими событиями этого заказа, с другими заказами и после устранения причины сбоя.
+
+**Критерий выполнения:** Самостоятельно построена история нарушения. Обоснованы сохранение порядка в исправленной схеме, независимая обработка других заказов и продолжение работы после устранения причины сбоя.
+
+### Пример 2. Переназначение задания
+
+#### Основная часть — до 4 баллов
+
+Координатор выдаёт задания исполнителям A и B, хранит состояние и не падает. Исполнители возвращают результаты вычислений без внешних побочных эффектов. Сообщения задерживаются и повторяются; исполнители могут остановиться. Повторное вычисление допустимо, но координатор должен сохранить не более одного результата каждого задания. Если исполнитель перестал отвечать, задание переназначают; при работающем исполнителе и восстановлении связи оно должно завершиться.
+
+Опишите, как координатор проверяет состояние исполнителей, когда переназначает задание и как принимает результаты разных попыток. Объясните, как ваше решение предотвращает сохранение нескольких результатов и позволяет завершить задание после отказа исполнителя.
+
+Рассмотрите ситуацию: A перестал отвечать, и координатор переназначил задание B. Может ли A продолжать работу? Как поступить, если затем пришёл его результат? Что делать, если после завершения задания приходят повторное сообщение с результатом или запоздалое сообщение о ходе выполнения?
+
+#### Первый уровень усложнения — 1 дополнительный балл
+
+Задание состоит из последовательно обрабатываемых элементов. Исполнитель продолжает отправлять heartbeat, но больше не завершает обработку новых элементов. Предложите показатель прогресса и правило, по которому координатор заподозрит зависание текущей попытки. Как учитывать повторные и задержанные сообщения? Может ли такая проверка ошибочно заподозрить исправного исполнителя? Объясните почему.
+
+**Критерий выполнения:** Предложены показатель полезного прогресса и правило его проверки. На примере повторных или задержанных сведений объяснены поведение проверки и ограничения выводов об отказе.
+
+#### Второй уровень усложнения — 2 дополнительных балла за оба уровня
+
+Теперь у вычислений появляются внешние побочные эффекты: исполнители записывают данные задания в общее хранилище. Для каждого задания координатор выдаёт возрастающие номера полномочий; каждая запись содержит такой номер. Для каждого задания хранилище запоминает наибольший увиденный номер. Проверка номера и изменение данных выполняются атомарно: запись с меньшим номером отклоняется. Хранилище доступно и допускает отдельную установку номера координатором.
+
+Координатор выдал B новый номер и объявил передачу права завершённой, но хранилище узнает этот номер только из первой записи B. Может ли A после этого ещё записать данные? Покажите нарушение и исправьте порядок передачи так, чтобы после её завершения записи A отклонялись.
+
+**Критерий выполнения:** Приведена допустимая история нарушения и исправлен порядок передачи полномочий. Объяснено, почему после завершения передачи прежний исполнитель не может записать данные, в том числе при задержках и повторах сообщений.