Соблазн собрать «правильный» кластер на старте велик — и почти всегда вреден. Вы платите сложностью за нагрузку, которой ещё нет: оркестрация, сетевые задержки, распределённые баги, дороже эксплуатация.
Начните с метрик, а не с предчувствий
Один хорошо настроенный сервер тянет на удивление много. Прежде чем масштабироваться, поставьте измеримые метрики: p95 latency, загрузка CPU, длина очередей, время ответа БД. Решения принимаются по графикам, а не по ощущению «кажется, пора».
Часто «тормозит» не сервер, а один тяжёлый запрос без индекса или N+1 в ORM. Профилирование экономит вам целый кластер.
Порядок масштабирования
Сначала — вертикально (больше CPU/RAM) и дешёвые победы: кэш (Redis), индексы, пул соединений (PgBouncer), вынос статики на CDN. Потом — реплика на чтение. И только когда упёрлись по-настоящему — горизонталь и шардирование.
Каждая новая нода должна решать измеренную проблему, а не гипотетическую.
Горизонтальное масштабирование добавляет не только мощность, но и классы проблем: согласованность, идемпотентность, распределённые транзакции. Берите их осознанно.
Практичный дефолт для большинства продуктов: один сервер в Docker, реплика БД, Redis и бэкапы. Этого хватает до серьёзных объёмов — а дальше вы уже будете точно знать, что именно упёрлось.