# NATS JetStream - Event Bus #sympozium #architektura #nats #messaging ## Rola w systemie NATS JetStream pełni rolę **centralnego event bus** łączącego wszystkie komponenty Sympozium. Jest deployowany jako StatefulSet w namespace `sympozium-system`. ## Dlaczego NATS? | Cecha | Wartość dla Sympozium | |-------|----------------------| | **Durable pub/sub** | Wiadomości nie są tracone przy restartach podów | | **Replay** | Kanały mogą odtworzyć niezrealizowane wiadomości | | **Lightweight** | Minimalne zasoby vs Kafka/RabbitMQ | | **Cloud-native** | Natywne wsparcie K8s | | **Decoupling** | Kanały i agenty nie muszą wiedzieć o sobie | ## Topologia ``` ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ Channel Pods │ │ NATS │ │ Controller │ │ (Telegram, │────►│ JetStream │◄────│ Manager │ │ Slack, etc.)│◄────│ │────►│ │ └──────────────┘ │ StatefulSet │ └──────────────┘ │ sympozium- │ ┌──────────────┐ │ system │ ┌──────────────┐ │ IPC Bridge │────►│ │ │ Schedule │ │ (sidecars) │◄────│ │ │ Router │ └──────────────┘ └──────────────┘ └──────────────┘ ``` ## Połączenie Wszystkie komponenty łączą się pod adresem: ``` nats://nats.sympozium-system.svc:4222 ``` Zmienna środowiskowa: `EVENT_BUS_URL` ## Wzorzec komunikacji 1. **Request/Reply** - tool execution (request → sidecar → result) 2. **Pub/Sub** - lifecycle events (run.started, run.completed) 3. **Queue Groups** - channel messages (load-balanced between consumers) ## Dlaczego nie bezpośrednia komunikacja? Agent pod nie ma dostępu sieciowego (NetworkPolicy deny-all). Jedyny komponent z dostępem do NATS to **IPC Bridge sidecar**. To zapewnia: - Agent nie może bezpośrednio komunikować się z innymi podami - Całość komunikacji przechodzi przez kontrolowany kanał - Łatwe auditowanie (jeden punkt wejścia/wyjścia) --- Powiązane: [[Przepływ danych i IPC]] | [[Control Plane]] | [[NetworkPolicy i izolacja sieciowa]]