Войти
Работаем: пн–пт 9:00–18:00Начать диагностику
Когда система выходит за пределы одного узла, появляется новая реальность. Сеть может задержать пакет. Узел может быть жив, но недоступен. Два экземпляра могут видеть разные состояния. Реплика может отставать. Повторный запрос может прийти после успешной операции. AMPE использует distributed architecture там, где масштаб, доступность или география действительно требуют распределённости и её сложность оправдана требованиями.
Начать диагностикуStateless-сервис легко масштабировать горизонтально.
Но состояние всё равно находится где-то: в БД; в кэше; в очереди; в distributed storage.
Если bottleneck остаётся в одном stateful-компоненте, количество frontend-инстансов не меняет потолок системы.
Разделение данных позволяет распределить нагрузку.
Но запрос, который раньше был локальным, может стать cross-partition.
Неудачный ключ создаёт hot partition.
Rebalancing требует ресурсов.
AMPE выбирает partition key по реальному профилю доступа, а не только по равномерности количества записей.
Когда один узел больше не даёт достаточного throughput.
Когда требуется высокая доступность в нескольких failure domains.
Когда объём данных превышает практический предел одной системы.
Когда нагрузка географически распределена.
Когда отдельные участки должны масштабироваться независимо.
Когда нужен graceful degradation при частичном отказе.
Когда архитектура уже распределена фактически, но её свойства не формализованы.
Read replica разгружает primary.
Но replica lag означает, что сразу после записи чтение может вернуть старое состояние.
Для аналитики это нормально. Для проверки только что изменённого баланса — возможно, нет.
AMPE определяет, где stale read допустим, а где требуется более сильная consistency.
Два инстанса могут получать одинаковое количество запросов и иметь совершенно разную загрузку.
Один обрабатывает лёгкие reads. Другой — тяжёлые exports.
Поэтому балансировка оценивается вместе с cost profile операций и состоянием downstream-зависимостей.
Один сервис отвечает. Второй — медленно. Третий недоступен. Четвёртый отдаёт stale data.
Система должна понимать, какой результат всё ещё можно отдать.
AMPE проектирует: timeouts; fallback; circuit breakers; bulkheads; degraded modes.
Не каждый частичный отказ должен превращаться в полный отказ продукта.
Чем сильнее несколько узлов должны одновременно соглашаться о состоянии, тем выше цена consistency.
Иногда она оправдана.
Иногда лучше изменить границу операции и принять eventual consistency.
AMPE не пытается делать всё распределённым и строго согласованным одновременно без причины.
Нагрузка определяет точки масштабирования.
Данные — границы partitioning и consistency. Failure model — replication и failover. SLO — допустимую деградацию. Observability — способность увидеть состояние распределённой цепочки.
Так high-load архитектура строится вокруг реального поведения системы, а не вокруг количества серверов.
Границы масштабирования становятся понятными.
Partitioning и replication имеют объяснимую логику.
Частичный отказ не обязательно приводит к полной недоступности.
Consistency выбирается по смыслу данных.
Capacity планируется по реальному профилю нагрузки.
И главное — распределённость становится контролируемым архитектурным свойством, а не источником случайной сложности.
Первый шаг
Для начала достаточно описать, какое ограничение заставляет систему становиться распределённой: нагрузка, объём данных, доступность или география. Диагностика покажет, где распределённость действительно нужна и какие компромиссы она создаёт.