Brainstorm: microservice patterns (Event Bus, Saga, Idempotency, logging)

BRAINSTORM-MICROSERVICES-2026-02-21.md

@@ -0,0 +1,65 @@
+# Брейншторм: Микросервисные паттерны
+Дата: 2026-02-21
+
+## Контекст
+Team Board = микросервисная архитектура: Tracker (ядро), Picogent (агенты), Bridges (Telegram, OpenClaw), Web Client, BFF.
+
+## Принятые паттерны
+
+### ✅ Event Bus (Redis Streams) — КЛЮЧЕВОЕ
+Redis Streams как шина событий между Tracker и потребителями.
+
+**Проблема:** WS-событие теряется если клиент offline. При reconnect — пропущенные сообщения потеряны.
+
+**Решение:** Tracker пишет события в Redis Stream → потребители (agents, bridges) читают из stream. Если потребитель был offline → при reconnect читает с последнего обработанного offset.
+
+**Плюсы:**
+- Persistent queue — события не теряются
+- Consumer groups — несколько потребителей одного потока
+- Replay — можно перечитать историю
+- Redis у нас уже есть (порт 6380)
+
+**Статус:** нужно продумать детали (формат событий, consumer groups, retention policy).
+
+### ✅ Saga Pattern (компенсации)
+Каждый шаг агента имеет компенсацию при сбое.
+
+Пример:
+1. `take_task(42)` → задача in_progress
+2. Агент работает...
+3. Агент упал (heartbeat timeout)
+4. Компенсация: задача → todo, комментарий "Агент упал, задача возвращена"
+
+### ✅ Idempotency
+Каждое сообщение/событие имеет уникальный ID.
+Повторная доставка с тем же ID → игнорируется.
+Критично для reliable delivery через Event Bus.
+
+### ✅ Centralized Logging
+Все сервисы: structured JSON logging (Pino для Node.js, structlog для Python).
+Единый формат → возможность агрегации.
+
+### ✅ Circuit Breaker
+Exponential backoff при недоступности Tracker.
+Picogent уже реализует (1s → 2s → 4s → ... → 30s cap).
+Event Bus частично решает: если Tracker упал, события копятся в Redis.
+
+## Отклонённые
+
+### ❌ Service Discovery
+Один Tracker — overkill.
+
+### ❌ API Gateway (BFF для всех)
+Бессмысленно отдельный BFF если все через него. BFF остаётся только для Web Client.
+
+### ❌ Health Check / Readiness Probe
+Агенты должны быть доступны по IP:port — слишком сложно. Heartbeat через WS достаточен.
+
+## На подумать
+
+### ⚠️ Event Bus: детали реализации
+- Tracker пишет в Redis Stream или в Redis Pub/Sub?
+- Streams = persistent, Pub/Sub = volatile
+- Consumer groups для multi-instance агентов?
+- Retention policy (сколько хранить)?
+- WS остаётся как транспорт до клиента, но sourced из Redis?