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

1. 1. Архитектура как набор решений

   Как защитить архитектуру сервиса измерениями и явными компромиссами?

2. 2. Архитектура начинается с проверяемого требования

   Название технологии не является результатом для пользователя.

3. 3. Форма нагрузки выбирает полезные механизмы

   Чтения, записи и размер задач оцениваются отдельно.

4. 4. Инварианты проходят через все компоненты

   Локальные успехи должны складываться в общий контракт.

   Один taskId на ключ

   Принятые задачи сохранены

   Один локальный результат

   Состояния не противоречат

5. 5. Ответ accepted имеет точное значение

   Задача принята устойчиво, но ещё не выполнена.

6. 6. Схема следует за движением задачи

   Каждый переход имеет данные и владельца.

7. 7. Режим чтения выбирается для операции

   Проверка исхода требует достаточной свежести.

8. 8. Две локальные границы соединены повтором

   Общей транзакции с брокером нет.

9. 9. Потерянный ответ проверяет целостность проекта

   Повтор должен вернуть прежнюю задачу.

10. 10. Поздний ACK проверяет границу эффекта

    Повтор доставки читает зафиксированный исход.

11. 11. Неизвестность получает путь разрешения

    Тайм-аут не создаёт новое бизнес-действие.

12. 12. Зависимости ограничивают общую доступность

    Наличие копий одного компонента не копирует остальные.

13. 13. Таблица отказов связывает механизм с обещанием

    Для каждого сценария определён допустимый режим.

14. 14. Последовательный путь расходует общий дедлайн

    Складываются интервалы одной операции.

15. 15. Обязательные ветви ждут самую медленную

    Параллельность меняет форму задержки.

16. 16. Мощность исполнителей имеет явные предпосылки

    Сначала вычисляем грубую границу, затем измеряем.

17. 17. Очередь покупает время, но не мощность

    Постоянный перегруз неизбежно накапливает работу.

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

    Узкое место определяется распределением запросов.

19. 19. Надёжность расходует ресурсы и сложность

    Каждая дополнительная гарантия имеет цену.

20. 20. Вычисление приближают к тяжёлым данным

    Перенос задачи и перенос данных имеют разную цену.

21. 21. Управление полномочиями тоже является зависимостью

    Отказ координации меняет право обслуживания.

22. 22. Альтернатива должна удовлетворять тем же требованиям

    Сравниваем эффект изменения, а не длину схемы.

23. 23. Запись решения сохраняет причину выбора

    Читатель должен восстановить аргумент без автора.

24. 24. Защитите решение по данным, а не названию

    Выберите изменение и назовите предел гарантии.

    Показать узкое место

    Сравнить два изменения

    Запросить нужный опыт

25. 25. Защита связывает обещание, механизм и опыт

    Каждый вывод имеет проверяемую границу.

26. 26. Решения для нашего сервиса

    Связать каждое требование с механизмом и проверкой.

    Рассчитать условный бюджет и назвать его предпосылки.

    Защитить альтернативу по фактическому отчёту и ограничениям.