Software Architect · Модуль 13
Performance — это не ощущение, что код быстрый. Это измеримые цели, профилирование и понятная цена оптимизации.
Latency · throughput · profiling · caching · budget
Оптимизировать нужно bottleneck, а не место, которое просто выглядит некрасиво.
Latency и throughput — разные вещи
Такси быстро довозит одного человека. Метро перевозит тысячи. Сравнивать их одним словом «быстро» бессмысленно.
Latency — время ответа для одной операции. Throughput — сколько операций система обрабатывает за период. Можно снизить latency одного запроса и ухудшить throughput всей системы, например агрессивным parallelism без контроля ресурсов.
Архитектор должен формулировать performance requirement конкретно: p95 response time, p99 tail latency, requests per second, batch duration, cold start, memory budget. «Должно быть быстро» не является требованием.
Кэш — это ответственность за устаревание
Копия меню на витрине полезна, пока цены совпадают с кассой. Потом она становится источником конфликтов.
Caching ускоряет чтение, но добавляет invalidation, TTL, consistency model и риск stale data. Перед кэшем стоит спросить: что именно дорого, как часто меняется, можно ли показать устаревшее значение, как сбросить кэш при изменении source of truth.
Кэшировать без понимания модели данных опасно: можно ускорить неправильный ответ.
Хорошая оптимизация начинается с измерения и заканчивается проверкой результата.
Пример: slow endpoint через профилирование
Врач сначала ставит диагноз, а не сразу назначает операцию, потому что пациент сказал «где-то болит».
Endpoint /dashboard имеет p95 2.8 секунды. Tracing показывает: 80% времени уходит на N+1 запросы к базе и отсутствие индекса по workspace_id, created_at. Команда добавляет eager loading, индекс и performance test.
Результат: p95 становится 380 ms. Решение точечное, измеримое и не добавляет лишнюю архитектурную сложность.
Антипример: переписать на Go без профиля
Поменять двигатель бессмысленно, если машина стоит в пробке из-за закрытой дороги.
Команда решает переписать сервис на другой язык, потому что «Python медленный». Позже выясняется, что 90% времени занимали внешние API и плохо спроектированные SQL-запросы.
Язык может быть bottleneck, но это нужно доказать. Иначе оптимизация превращается в дорогой refactor без бизнес-эффекта.
- Какая метрика performance важна именно здесь? - Где bottleneck по данным profiler/tracing? - Какой budget считается приемлемым? - Что сломается при кэшировании?