Содержание слайдов

1. 1. Система начинается с отказа

   Что сервис обязан сохранять, когда часть системы недоступна?

2. 2. Успех API создаёт обязательство системы

   Подтверждённая задача должна сохраниться в заявленной модели отказов.

3. 3. Компоненты сервиса отказывают по-разному

   Процесс API, хранилище и брокер могут отказывать по-разному.

4. 4. Клиент и сервер видят разный исход

   Одна сторона изменила состояние, другая об этом не узнала.

5. 5. Crash-stop исключает дальнейшие шаги процесса

   Остановившийся участник не возвращается в этом исполнении.

6. 6. При восстановлении важна память, пережившая процесс

   Оперативная память теряется; подтверждённые устойчивые записи должны сохраниться.

7. 7. Сообщение может исчезнуть, повториться или опоздать

   Порядок доставки по сети не обязан совпадать с порядком вызовов.

8. 8. После фиксации ответ может исчезнуть

   Синтетический трейс одной принятой задачи.

9. 9. Молчание не доказывает смерть участника

   Медленное вычисление и разрыв сети могут выглядеть одинаково.

10. 10. Ложный ответ требует другой модели защиты

    Crash-протокол не обязан терпеть произвольное нарушение правил.

11. 11. Модель стенда задаёт область обещаний

    Потерю всех устойчивых копий не имитируем как обычный отказ узла.

12. 12. Безопасность запрещает плохое состояние

    Один ключ не должен породить две разные задачи.

13. 13. Продвижение требует условий среды

    После восстановления обработка должна продолжиться.

14. 14. Сохранённые данные могут быть временно недоступны

    Отсутствие ответа ещё не означает потерю записи.

15. 15. Инвариант связывает записи между собой

    Для проверки нужны ключи, задачи и результаты.

16. 16. Базовый эффект находится внутри хранилища

    Эффект лабораторной — сохранённый результат задачи.

17. 17. Подтверждение следует после устойчивого решения

    Порядок «ответить, затем сохранить» нарушает обещание.

18. 18. Неизвестный исход — отдельное состояние клиента

    Он требует выяснения результата, а не догадки.

19. 19. Создание связывает состояние и намерение доставки

    Task, idempotency и outbox фиксируются одной транзакцией.

20. 20. ACK следует после фиксации результата

    Result, dedup, completed и counter обновляются вместе.

21. 21. Для завершения нужны несколько живых зависимостей

    etcd, брокер и исполнитель (worker) выполняют разные обязанности.

22. 22. Потеря ACK не требует второго результата

    Синтетический трейс: задача T7, два получения сообщения.

23. 23. Тест отказа проверяет восстановленное состояние

    «Процесс не упал» недостаточно для инварианта.

24. 24. Нарушен инвариант или остановлен прогресс?

    Три истории требуют разных выводов.

25. 25. Отчёт начинается с обещания и предположений

    Потом идут сценарий, наблюдения и вывод.

26. 26. После лекции вы сможете

    Отделить наблюдение от предположения об отказе.

    Сформулировать безопасность и условия продвижения.

    Проверить подтверждённую задачу после сбоя.