Коротко: три подхода — односерверный многопоточный/async, распределённый (Kafka + stream processors), serverless — имеют разные сильные стороны и ограничения. Ниже — сравнение по ключевым факторам (латентность, устойчивость, экономика), рекомендации когда применять каждый подход и конкретная архитектура, позволяющая выдержать SLA <500 ms.

1) Краткое сравнение подходов

A. Многопоточность внутри одного сервера (thread pools, async I/O)

Плюсы:
Низкая абсолютная задержка (нет сетевой накладной при локальной обработке).Простота развертывания и отладки.Невысокие операционные затраты при малых нагрузках.Минусы:
Ограниченная масштабируемость (CPU/IO/память одной машины).Один отказ = отказ всего сервиса (SPOF) без сложного HA.Сложно обеспечить stateful processing с высокой доступностью и recovery.При перегрузке latency и loss резко ухудшаются.Когда подходит:
Небольшой объём логов, строгие требования к p99 низкой латентности в контролируемой среде (LAN), не требуется глобальная масштабируемость или долгосрочное хранение.

B. Распределённая система (Kafka + stream processors: Flink, Kafka Streams, ksqlDB, Spark Structured Streaming)

Плюсы:
Горизонтальная линейная масштабируемость (partitioning).Долговременное надёжное буферирование (Kafka) -> устойчивость к всплескам и временным сбоям.Поддержка stateful processing с checkpointing и exactly-once (в зависимости от стека).Богатые возможности для упорядоченности, reprocessing, аналитики.Минусы:
Большее операционное управление (кластеры Kafka, ZK/KRaft, stream engine).Некоторая сетевоя/сериализационная накладная — но при правильной настройке пусковой латентности можно удержать на десятки–сотни миллисекунд.Стоимость — постоянная инфраструктура (брокеры, storage, compute).Когда подходит:
Высокие и/или переменные объёмы, требования к надёжности, упорядоченности, stateful обработке, возможность re-processing/Backfill.

C. Serverless-функции (AWS Lambda / GCP Cloud Functions / Azure Functions)

Плюсы:
Простая автошкалация, оплата по вызову, быстрое развитие.Хороши для эпизодических/взрывных нагрузок и для дешёвой обработки небольших объёмов.Минусы:
Cold starts (если не использовать provisioned concurrency) — непредсказуемые задержки.Ограничения по времени выполнения, памяти, у stateful-процессинга — сложнее обеспечить exactly-once.Стоимость при постоянной высокой частоте может быть выше, чем у reserved infra.Труднее обеспечить согласованное упорядочивание и сложные stateful операции.Когда подходит:
Bursty, нерегулярные нагрузки; простая фильтрация/маркировка/пересылка логов; когда важна скорость разработки и операционное упрощение.

2) Компромиссы по ключевым показателям

Задержка (latency)

Односерверный: минимальная сетевоя накладная; p50/p95 отлично, но p99 может деградировать при нагрузке.Kafka+stream: базовая латентность = клиент→broker + broker→consumer + процессинг; типично десятки–несколько сотен мс при правильной тюнинге; Flink/Kafka Streams могут обеспечить sub-500 ms end-to-end.Serverless: холодные старты и сетевые вызовы к внешним системам увеличивают вариативность; с provisioned concurrency и локальным буфером возможно <500 ms, но дорого и непросто в пиковые нагрузки.

Устойчивость к сбоям (fault tolerance / durability)

Односерверный: низкая — нужен кластер/репликация на уровне приложений.Kafka+stream: высокая — данные в Kafka долговечно, обработчики с checkpointing/replication восстанавливаются; легко сделать durable retries/DLQ.Serverless: устойчивость зависит от архитектуры (обычно входной буфер + DLQ). Конкретные функции часто не имеют локального durable state, зато легко переиспользуют другие durable сервисы.

Экономика (TCO, оперативные затраты)

Односерверный: дешевле для низких нагрузок; при росте быстро становится неэффективным и рискованным.Kafka+stream: выше fixed cost (кластер), но лучшая цена за throughput на больших объёмах; админские затраты.Serverless: минимальные фиксированные расходы, но стоимость на 1M запросов может превышать стоимость держания кластера при постоянной высокой нагрузке; provisioned concurrency → фиксированные расходы.

3) Практические инженерные детали для низкой латентности (<500 ms) с Kafka+stream

Ingress:

Используйте легковесные агент‑коллекторы (Vector/Fluent Bit/Fluentd) на хостах/edge; агенты буферизуют и бэчят до Kafka, уменьшая сетевую нагрузку.Если отправлять напрямую из приложений — настроить async producers, small linger.ms (1–5 ms), batch.size разумно, compress (lz4/snappy) — компрессия уменьшит пропускную способность, но добавит CPU; lz4 хорош баланс.Producer acks: acks=all с replication.factor >=3 и min.insync.replicas=2 для устойчивости, но это добавляет задержку; для строжайшего SLA при высокой критичности можно рассмотреть acks=1 + репликация с компенсирующими механизмами (но это риск потерь).

Kafka:

Partitioning: количество partition >= ожидаемая параллельная обработка; правильный ключ для баланса.Broker HW: SSD для log.paths, хорошая сеть (10Gbps), low latency NICs.Replication factor 3, min.insync.replicas 2.Настройки retention и segment.bytes по рабочей нагрузке.Monitor lag, ISR, controller stability.

Stream processing:

Выбор: Flink (лучше для сложного stateful processing и EOS), Kafka Streams (легковеснее, tight Kafka интеграция, хорош для simple stateful ops), ksqlDB (SQL-подход).Для <500 ms:Установите commit/checkpoint interval малым (например 100–500 ms), но учтите рост I/O и CPU.Используйте RocksDB state backend, размещение на SSD для быстрых checkpoint/restore.Tune parallelism: достаточное число task slots, равномерное распределение ключей.Параллельная обработка и non-blocking I/O внутри операций.Используйте exactly-once semantics, если нужен консистентный state и отсутствие дубликатов. EOS добавляет накладную — обычно допустимая для p95/p99 в сотни миллисекунд.

Sink и downstream:

Выводите результаты в низколатентные хранилища (Elasticsearch, ClickHouse, Redis, Timescale/Influx, materialized Kafka topics).Sinks должны поддерживать батчинг и retry с DLQ.Для пользовательских API/alerts — кэширование и агрегация, чтобы не вызывать тяжёлые запросы по каждому событию.

Backpressure и spike handling:

Kafka даёт буфер и возможность «отложенного» потребления; stream processors должны корректно обрабатывать backpressure.Пределы входа (rate limiting), shedding и graceful degradation: возможно, при перегрузке переключить часть менее критичных логов в batch/low-priority pipeline.Слой ingress должен иметь локальное durable buffer, чтобы не терять данные при кратковременных пиках.

4) Serverless — практические замечания если всё же использовать

Чтобы уложиться в <500 ms:
Используйте provisioned concurrency, avoid cold starts.Держите функции краткими, минимизируйте сетевые вызовы; старайтесь отказаться от пер‑инвокационных init.Вместо direct processing каждого события, функции лучше агрегируют/бэчят события в Kafka/managed streaming, чтобы снизить количество вызовов.При долгом stateful-процессинге serverless не лучшая опция.

5) Рекомендуемая архитектура для SLA <500 ms (рекомендация: Kafka + Flink/Kafka Streams + edge agents)

Компоненты (high-level):

Edge: локальные агенты (Vector/Fluent Bit) на источниках логов — буферизация, фильтрация, batching, TLS → Kafka.Ingress API (опционально): nginx/ALB + lightweight ingress service для клиентов, который пишет в Kafka asynchronously. Для мобильных/публичных клиентов — использовать CDN/edge + buffering.Kafka cluster:
RF=3, min.insync.replicas=2.Partitions ≥ ожидаемого параллелизма.SSD, хорошая сеть, мониторинг (Lag, ISR).Stream processing:
Flink (рекомендую) или Kafka Streams:State backend = RocksDB.Checkpoint interval = 200–500 ms (или меньше, в зависимости от тестов).Parallelism tuned to throughput.Exactly-once enabled (если требуется).Логика: enrichment, dedup, aggregation/windowing, alerting.Output:
Материализованные топики в Kafka для downstream.Быстрые хранилища для realtime (Elasticsearch/ClickHouse/Redis).OLAP/архив в S3/HDFS для длительной аналитики.Operations:
Kubernetes с оператором (Strimzi/Confluent Operator/Flink operator) или managed Kafka (MSK, Confluent Cloud) для снижения опернагрузки.Мониторинг: Prometheus+Grafana, alerts на p99 latency, consumer lag, broker metrics.DLQ + retry policies.Canary releases, chaos testing, load tests.

Latency budget (пример):

Edge agent batching & network to Kafka: 10–50 ms (внутри региона).Kafka broker write + replication: 5–100 ms (зависит от acks и ISR).Streams processing (processing time + checkpointing): 50–300 ms (зависит от сложности).Sink write: 10–100 ms.
Итого: при оптимизации и короткой логике можно держать E‑2‑E < 500 ms для большинства событий; p99 требует тщательного тестирования и резервирования.

6) Операционные рекомендации / checklist перед запуском SLA

Провести нагрузочное тестирование (пиковые нагрузки + длительные spikes) и измерять p50/p95/p99.Настроить и протестировать recovery: failover брокера, failover stream tasks, restore from checkpoint, producer retry policies.Настроить alerting: consumer lag > threshold, long GC, disk usage, network errors.План capacity: увеличение partition + потоков при росте.Подумать о мульти‑AZ: сохраняйте все компоненты в одном регионе для минимальной латентности; межрегиональная репликация добавляет сотни ms.Формализуйте SLOs/Penalties, тестируйте при degradations (disk full, network partition).

7) Когда выбрать что

Малые стабильные объёмы, строжайшая p99 (локальная среда): односерверный высокопроизводительный сервис с репликой.Высокие/переменные объёмы, требования к доверию и ре-обработке: Kafka + Flink/KStreams (рекомендую).Быстрый MVP, нерегулярные нагрузки, нестрогие SLA: serverless (с буфером в Kafka/managed streaming).

Заключение (конкретная рекомендация)
Для реального продакшна с SLA <500 ms при реальных объёмах логов я рекомендую: edge agents → Kafka (RF=3, minISR=2) → Flink (RocksDB, небольшие checkpoint intervalы, parallelism по partition) → низколатентные sinks. Разместить всё в одном регионе, оптимизировать producer batching, использовать мониторинг и стресс‑тесты. Это даст баланс низкой латентности, высокой устойчивости и контролируемых затрат (при больших объёмах экономичнее, чем pure serverless).

Если нужно, могу:

Предложить схему конфигураций (примеры значений linger.ms, batch.size, checkpoint interval) под вашу ожидаемую QPS и объём сообщения.Нарисовать последовательность обработки/таймлайна событий (latency budget).Составить план нагрузочного тестирования (scenarios, metrics).