Оптимизация отклика backend: очереди, async, backpressure

1) Зачем: цели и SLO

Цель — стабильный быстрый отклик даже под всплесками. Бизнес выражает это SLO:

API (CRUD/каталоги): p95 ≤ 250–400 мс, error rate < 1%.
Платёж/сеттлмент (асинхронно): внутренний SLA на подтверждение ≤ 2–5 мин, а клиенту — мгновенный 202/Accepted + статус-поллер/вебхук.
WS/real-time: RTT p95 ≤ 120 мс, disconnect ≤ 0.5%.

Ключ: развязать «медленные» шаги (провайдеры, БД, внешние API) от пользовательского отклика через очереди и грамотное ограничение нагрузки.

2) Базовая картина: где берётся латентность

Узкие места: БД (пулы/индексы), внешние провайдеры (PSP/игровые), блокирующие I/O, GC/стоп-мир, сериализация JSON, «тяжёлые» агрегации.

Симптомы: рост p99, очередь соединений к БД, всплески ретраев, тайм-ауты цепочкой (retry storm).

Антидот: асинхронные конвейеры + backpressure + тайм-ауты/ретраи + идемпотентность.

3) Асинхронные паттерны: SEDA и CQRS

SEDA (staged event-driven architecture): разбейте обработку на стадии (ingress → валидация → запись → интеграция → уведомление). На каждой — своя очередь и лимиты параллелизма.

CQRS: разделите чтения и записи. Запись — в журнал/базу, чтение — из проекций/кэшей.

Outbox: событие публикуется атомарно вместе с записью (избегаем «потерянных» сообщений).

Saga: долгие бизнес-процессы с компенсирующими транзакциями вместо глобальных.

4) Очереди и стримы: выбор и тюнинг

RabbitMQ / NATS JetStream — команды задач (work queues), Kafka — события/стримы с реплеем.

Настройки, которые влияют на отклик:

Prefetch / max in-flight: ограничьте количество одновременно обрабатываемых сообщений на воркера (например, 16–64), чтобы не «забить» БД/внешний API.
Акер/повторы: `ack` после идемпотентной записи; повторы с экспоненциальной задержкой и джиттером.
DLQ/parking lot: безконечных ретраев нет — после N попыток уходит в Dead Letter Queue.
Партиционирование (Kafka): ключ по сущности (userId/txnId) для упорядоченности; параллелизм через количество партиций.

5) Обратное давление (backpressure) — как не утонуть

Идея: принимать только столько, сколько сможете обработать в пределах латентности SLO.

Техники:

Admission control: ограничивайте конкуренцию (semaphore/worker-pool) на каждую внешнюю зависимость: БД, PSP, провайдер игр.
Шейпинг трафика: token-bucket/leaky-bucket на входе сервиса и на критичных маршрутах.
Очереди с верхней границей: при заполнении — отрезаем хвост (429/503 + Retry-After) или переводим в asap-batch.
Adaptive concurrency (AIMD): растите параллелизм при успехе, снижайте при тайм-аутах.
Circuit Breaker: `closed → open → half-open` по ошибкам/тайм-аутам внешнего API; при open — деградация (кэш/стаб).

Псевдокод (Go-подобно):

go sem:= make(chan struct{}, 64) // лимит конкуренции к БД/PSP

func handle(req) {
select {
case sem <- struct{}{}:
defer func(){ <-sem }()
ctx, cancel:= context.WithTimeout(req.ctx, 300time.Millisecond)
defer cancel()
res, err:= db.Do(ctx, req)
if err == context.DeadlineExceeded { metrics.Timeouts.Inc(); return TooSlow() }
return Ok(res)
default:
metrics.Backpressure.Inc()
return TooBusy(429, "Retry-After: 0.2")
}
}

6) Тайм-ауты, ретраи и джиттер: «три кита выживания»

Тайм-ауты короче SLO: если SLO 400 мс, тайм-аут к БД/провайдеру 250–300 мс; общий тайм-аут запроса < 400–600 мс.

Ретраи ограниченные и умные: 1–2 попытки max, только для безопасных операций (идемпотентных), с экспонентой и джиттером.

Коалесcинг: агрегируйте повторы для одного ключа.

Псевдокод (экспонента + джиттер):

python for attempt in range(0, 2):
try:
return call(dep, timeout=0.3)
except Timeout:
backoff = (0.05 (2attempt)) + random.uniform(0, 0.05)
sleep(backoff)
raise UpstreamUnavailable

7) Идемпотентность и дедупликация

Idempotency-Key на HTTP (депозиты, выплаты), `operation_id` в БД (уникальный индекс).

Inbox/Outbox: входящие вебхуки — всегда через неизменяемую inbox-таблицу с dedupe по `event_id`; исходящие — из outbox по транзакции.

Exactly-once «по смыслу»: допускаем повторные доставку/исполнение, но эффект один.

8) Быстрый API для медленных операций

Синхронный отклик: 201/202 + URL статуса (`/status/{id}`), ETA и подсказки ретрая.

Вебхуки/Server-Sent Events/WS — пуш стейта при готовности.

Клиентская дисциплина: `Retry-After`, идемпотентность, лимит опроса.

Пример ответа:

json
HTTP/1.1 202 Accepted
Location: /v1/withdrawals/req_9f2/status
Retry-After: 2
{
"request_id": "req_9f2",  "state": "processing",  "next_check_sec": 2
}

9) Минимизируем работу в горячем пути

Вынесите тяжёлые штуки в фон: преобразования, агрегации, уведомления, запись в DWH.

Кэш и проекции: часто читаемое — cache-aside с коротким TTL и событийной инвалидацией.

Batch-паттерны: группируйте внешние вызовы (напр., запрос лимитов провайдера раз в N мс).

Сериализация: быстрые кодеки (protobuf/msgpack) для межсервисных связей; JSON только на edge.

10) БД под контролем

Пулы соединений: верхние границы (исходя из ядер/IO), очереди к пулу включены.

Индексы и план: p95 explain + автотесты регрессии планов.

Тайм-ауты запросов: короткие, `statement_timeout` (Postgres).

Hot rows/locks: шардирование по ключу, оптимистичные блокировки (версия баланса), saga вместо «монолитной» транзакции.

11) WebSocket/real-time

Ограничитель на рассылку: batched broadcast, max msgs/sec per connection.

Внутренний backpressure: очередь исходящих сообщений с капом; при переполнении — drop low-priority.

Sticky-routing и PDB при релизах — чтобы не плодить reconnect-шторм.

12) Наблюдаемость, чтобы не гадать

Метрики (RED/USE + backpressure):

`request_rate`, `error_ratio`, `latency_p95/p99` по маршрутам.
`queue_depth`, `lag_seconds`, `consumer_inflight`, `retries_total`, `dlq_rate`.
`backpressure_drops`, `admission_rejects`, `circuit_open`.
Для БД: `connections_in_use/max`, `locks`, `slow_queries`.
Трейсы: спаны `queue → worker → db/psp` с тэгами `operation_id`, `partition`, `retry`.
Логи: структурные, с `trace_id`, без PII; отдельные события «open/close circuit».

13) Тестирование под нагрузкой

Open-model (arrivals/sec) для всплесков; Closed-model (VUs) для сессий.

Профили: краткие burst 60–120 с и soak 1–4 ч.

Инъекции отказов: замедлите внешнее API на +200–500 мс, посмотрите на p99/ретраи/очереди.

Критерии зелёной зоны: без роста `queue_lag`, стабильные p95, `dlq_rate≈0`.

14) Безопасность и надёжность

Очереди по TLS/mTLS, подпись сообщений, контроль схемы (Avro/Protobuf + Schema Registry).

Idempotent producer (Kafka), exactly-once tx там, где оправдано.

Хаос-режим: периодически «роняйте» зависимость и смотрите на деградацию (circuit, fallback).

15) Примеры «кусочков» конфигураций

Nginx/Envoy входной шейпинг:

nginx limit_req_zone $binary_remote_addr zone=api:10m rate=20r/s;
server {
location /api/ {
limit_req zone=api burst=40 nodelay;
proxy_read_timeout 0.6s;  # короче SLO proxy_connect_timeout 0.2s;
}
}

RabbitMQ (prefetch):


basic.qos(prefetch_count = 32) # баланс CPU/IO

Kafka consumer (Java-фрагмент):

java props.put(ConsumerConfig.MAX_POLL_RECORDS_CONFIG, 200);
props.put(ConsumerConfig.FETCH_MAX_BYTES_CONFIG, 5_000_000);
props.put(ConsumerConfig.MAX_POLL_INTERVAL_MS_CONFIG, 60_000);

16) Чек-лист внедрения (prod-ready)

Критичные пути разделены на синхронный отклик и асинхронную обработку (SEDA).
Admission control и лимиты конкуренции на внешние зависимости.
Тайм-ауты короче SLO; ретраи ≤ 2, с экспонентой и джиттером; коалессинг.
Circuit breaker + деградация (кэш/стаб), политика half-open.
Очереди/стримы: prefetch/in-flight, DLQ, партиции по ключам.
Идемпотентность (operation_id/Idempotency-Key), Outbox/Inbox, дедупликация.
Кэш: cache-aside, короткие TTL + событийная инвалидация.
БД: лимиты пулов, statement_timeout, индексы, анти-lock стратегии.
WS: лимиты сообщений, батчинг, sticky-routing, PDB.
Наблюдаемость: метрики backpressure/queues/retries, трейсы end-to-end, дашборды.
Нагрузочные и отказные тесты (open+closed, burst+soak), критерии зелёной зоны.

Резюме

Быстрый бэкенд — это не «сделать ещё один кэш», а управляемый поток: вход ограничен, тяжёлое — в фон, каждый этап с очередью и лимитами, ретраи редкие и умные, а цепочки защищены circuit breaker и идемпотентностью. Добавьте дисциплину тайм-аутов, наблюдаемость и регулярные стресс-тесты — и ваши p95/p99 останутся зелёными даже под бурстами и капризами внешних провайдеров.