01 / 25 · §0 · §18
Оси компромиссов
Любой выбор в backend — торговля по осям. Не «что лучше», а «что мы готовы отдать».
Нажми на схему, чтобы открыть в полном размере.
Главное
- Latency — как быстро один ответ. Throughput — сколько запросов в секунду. Батчинг растит второе ценой первого.
- Consistency — видят ли все одно и то же сразу. Strong (ждём) против eventual (быстро, но врозь) — это продуктовое решение.
- Durability — переживут ли данные сбой. Репликация и fsync надёжнее, но медленнее.
- Scalability — что будет при ×100. Stateless масштабируется легко, stateful — больно.
- Complexity · Cost · Dev speed — кто чинит в 3 ночи, сколько стоит и как быстро выкатим фичу.
Пример: лайк vs счётчик
«Лайк виден мгновенно» → strong consistency (дороже)
«Счётчик обновится через 2с» → eventual (дёшево, быстро)Что когда выбирать
- CAP: при сетевом разрыве выбираешь консистентность или доступность.
- Fallacies of Distributed Computing: сеть не надёжна, не бесплатна, latency не ноль.
- Choose Boring Technology: у команды ограниченный бюджет новизны — каждая экзотика тратит «токен».
Главное
К каждой «коробке» на схеме задавай два вопроса: какую ось она обслуживает и что отдаёт взамен.