TGViewer
Fedkin is thinking Fedkin is thinking @fedkin_thinking · 9.01K subscribers
Post #218 7.27K
Делать ли систему масштабируемой заранее

В ответ на https://t.me/fedkin_thinking/213?comment=2233

Это вопрос управления рисками. Можно пользоваться простой ментальной моделью:

- cost_prepare — стоимость подготовки
Сколько нам будет стоить сделать систему масштабируемой заранее

- growth_probability — вероятность роста нагрузки
Каков шанс, что нагрузка повысится до такого уровня, что текущая архитектура не вывезет

- cost_failure — стоимость фейла при внезапном росте нагрузки
Сколько нам будет стоить экстренно масштабировать систему + стоимость репутационных потерь, инцидентов, срочных фиксов и т.д.

Если мы заранее подготовим систему, то стоимость риска = cost_prepare

Если мы заранее не подготовим систему, то стоимость риска = growth_probability * cost_failure

cost_prepare > growth_probability * cost_failure => забиваем на преждевременное масштабирование

cost_prepare < growth_probability * cost_failure => заранее масштабируемся

---

Пример:
Текущая нагрузка 100rps, 1000 клиентов, сервис нормально работает

Допустим:
Стоимость доработать, чтобы сервис выдерживал 1000 rps = 100 человекочасов
Вероятность, что кол-во пользователей увеличится в 10 раз = 0.1
Стоимость экстренных доработок = 200 человекочасов

Если мы заранее подготовим систему, то стоимость риска = 100 человекочасов

Если мы заранее не подготовим систему, то стоимость риска = 0.1 * 200 человекочасов = 20 человекочасов

Значит заранее оптимизировать не очень осмысленно

---

На практике же нагрузка обычно редко вырастает одномоментно и зачастую есть пространство для маневра, чтобы адаптироваться

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

Как завещал Клеппман
An architecture that is appropriate for one level of load is unlikely to cope with 10 times that load. If you are working on a fast-growing service, it is therefore likely that you will need to rethink your architecture on every order of magnitude load increase or perhaps even more often than that.
  • 👍 47
  • 🔥 13
  • ✍ 2
  • 🤯 2
  • 💅 1
More from @fedkin_thinking
  1. Sep 20, 2026С большинством людей все в порядке Представь, у тебя команда регулярно срывает сроки ревью…
  2. Sep 19, 2026Чему техлиду научиться у Tinder На днях стало интересно, как запускаются сервисы с "сетевы…
  3. Sep 13, 2026Почему рабочие встречи превращаются в балаган — Раскатываем эксп на 100%? — Я бы не раскат…
  4. Sep 12, 2026Перед автоматизацией выясни, существует ли процесс Нулевой шаг автоматизации абсолютно чег…
  5. Aug 31, 2026Полезно понимать, какие проблемы решает твой руководитель Повышение обычно происходит, ког…
  6. Aug 29, 2026Все заняты, а продукт не двигается — Миш, вижу у тебя десять задач по бэку, какой статус?…
Threads Profile ViewerView any public Threads profile without an account.Open ThreadLook →Writing with AI? Make it sound human.Metric37 rewrites AI drafts so they read naturally. Free AI detector, 1,500 words free.Try Metric37 →