Low latency systems упираются не в CPU, а в коммуникации. Разбираем, как архитектура снижает latency без потери надежности.
Проблема проявляется не сразу — она становится заметной лишь тогда, когда система достигает пределов сетевого взаимодействия. В современных distributed systems рост (throughput) больше не означает снижение (latency). Наоборот, дополнительные уровни абстракции в облаке и сложность процессоров увеличивают задержки. Основное время уходит не на вычисления, а на передачу сообщений между компонентами. Попытка «залить проблему железом» — больше CPU, больше потоков — редко дает результат, потому что узкое место остаётся в коммуникации.
В low latency systems критична не только абсолютная задержка, но и предсказуемость. В системах наподобие трейдинга важна не средняя latency, а конкретная операция. Дополнительно latency влияет на recovery: пока система восстанавливается, она фактически недоступна. Это делает архитектурные решения вокруг обмена сообщениями ключевыми. Если система построена как цепочка сервисов с множеством hop’ов, деградация становится неизбежной.
Практический ответ на это — separation of concerns и контроль над каналами коммуникации. Подход, реализованный в LMAX Disruptor, показывает, что основной выигрыш приходит не из «новых алгоритмов», а из декомпозиции потоков работы. Журналирование, декодирование и бизнес-логика разделяются. Каждый поток делает одну задачу и не блокируется. Это снижает конкуренцию за ресурсы и устраняет лишние ожидания. В результате latency падает без изменения бизнес-логики.
Инструменты вроде Aeron развивают эту идею на уровне межпроцессного взаимодействия. Они дают контроль над тем, как именно передаются сообщения: UDP, multicast или IPC (inter-process communication). При этом архитектура допускает разные уровни компромиссов. IPC снижает latency за счёт shared memory, но требует размещения компонентов на одном хосте. Это типичный trade-off между распределённостью и скоростью.
Дальнейшее снижение latency связано с уменьшением слоев абстракции. Использование kernel bypass через DPDK позволяет обойти сетевой стек ОС и писать пакеты напрямую в NIC. Это убирает накладные расходы и даёт микросекундные задержки. Но цена — рост сложности и снижение переносимости. Такой подход оправдан только там, где latency — ключевая бизнес-метрика.
Интересно, что предел оптимизации — это отказ от сообщений как таковых. IPC всё ещё требует сериализации и десериализации. Если компоненты находятся в одном процессе, можно перейти к вызовам функций. В этом случае latency измеряется в наносекундах, а при инлайнинге — практически исчезает. Но это радикально ограничивает архитектуру и масштабируемость.
Здесь возникает ключевой архитектурный вопрос: можно ли построить систему, где канал коммуникации выбирается динамически? В одних случаях — сеть, в других — shared memory, в третьих — прямой вызов. Такой подход требует строгого контроля над потоками данных и часто опирается на модели вроде replicated state machines и consensus (например, Raft). Они позволяют сохранить консистентность при агрессивной оптимизации коммуникаций.
Итоговый вывод прагматичен. Low latency systems — это не про один инструмент. Это про управление границами: между потоками, процессами и машинами. Чем меньше этих границ и чем они прозрачнее, тем ниже задержка. Но каждая оптимизация увеличивает связанность системы и снижает гибкость. Баланс между этими факторами и определяет зрелость архитектуры.