Multi-Agent Sistemlerde İletişim: Kapsamlı Bir Teknik Rehber
Son güncelleme: Ocak 2026
Bir şirketin müşteri hizmetleri departmanını düşünün - telefona bakan biri var, mail'lere cevap veren başka biri, teknik destek için ayrı bir ekip... Hepsi aynı müşteriye hizmet etmek için sürekli birbirleriyle iletişim halinde olmalı. İşte multi-agent sistemler de tam olarak böyle çalışıyor.
Bu yazıda, agent'ların birbirleriyle nasıl haberleştiğini, hangi araçların ne zaman kullanıldığını ve gerçek dünya projelerinde bu teknolojilerin nasıl bir araya geldiğini inceleyeceğiz. Teorik bilgiler kadar pratik kod örnekleri de paylaşacağız.
Hızlı Bakış
Ne anlatıyoruz: Multi-agent sistemlerde agent'ların birbirleriyle nasıl iletişim kurduğu
Hangi araçlar: NATS, Redis, RabbitMQ, Kafka - her birinin güçlü ve zayıf yönleri
Mimari pattern'ler: Pub/Sub, Request-Reply, Event Sourcing, Orchestrator
Pratik içerik: Gerçek kod örnekleri, karar rehberi, production tavsiyeleri
Hibrit yaklaşım: MessageBus + A2A Protocol'ü birlikte kullanmak
Neden Agent İletişimi Bu Kadar Önemli?
Düşünsenize - bir restoran mutfağındasınız. Garson siparişi alıyor, kasaya yazıyor, şef görüyor, malzemeciyi çağırıyor, aşçılar hazırlıyor, sonra garson yemeği götürüyor. Bu zincirdeki herhangi bir kopukluk felaket demek.
Multi-agent sistemler de aynı mantıkla çalışıyor. Ses tanıma yapan bir agent, anlam çıkaran başka bir agent, aksiyon alan üçüncü bir agent... Hepsinin senkronize çalışması gerekiyor. Peki bu koordinasyon nasıl sağlanıyor?
Temel Kavramlar
Senkron vs Asenkron İletişim
İki temel iletişim modeli var:
Senkron (Telefon görüşmesi gibi):
- Agent A bir istekte bulunuyor, Agent B cevap verene kadar bekliyor
- Basit ve anlaşılır ama ölçeklenmiyor
- Agent A bloke oluyor, başka iş yapamıyor
Asenkron (E-posta gibi):
- Agent A mesajı bırakıyor, işine devam ediyor
- Agent B müsait olduğunda alıp işliyor
- Loose coupling - herkes bağımsız çalışabiliyor
- Debugging biraz daha zor olabiliyor
Temel Terimler
Konuya girmeden önce bazı terimleri netleştirelim:
Producer/Publisher: Mesaj üreten taraf - örneğin SpeechAgent transkript yayınlar
Consumer/Subscriber: Mesaj tüketen taraf - NLUAgent o transkripti dinler
Topic/Channel: Mesajların kategorisi - speech.transcribed, intent.detected gibi
Queue: Mesajların sıralı deposu
Broker: Mesajları yöneten ara katman - RabbitMQ, Kafka gibi
Event: Gerçekleşmiş bir olayın bildirimi - "Kullanıcı konuşmayı bitirdi"
Command: Bir işlem yapılması talebi - "Müzik çal"
Event vs Command Farkı
Bu ayrım çok kritik:
Event (Olay):
- Geçmişte olan bir şeyi bildirir
- İsimlendirme: Past tense (TranscriptionCompleted, MusicStarted)
- Publisher sonucu umursamaz
- Birden fazla subscriber olabilir
Command (Komut):
- Bir şey yapılmasını ister
- İsimlendirme: Imperative (PlayMusic, StopRecording)
- Sender sonucu bekler
- Tek bir handler olmalı
İletişim Modelleri
Pub/Sub Pattern
En yaygın model bu. Bir publisher mesaj yayınlıyor, ilgilenen tüm subscriber'lar alıyor.
Avantajları:
- Decoupled: Publisher subscriber'ları bilmek zorunda değil
- Scalable: Yeni subscriber eklemek çok kolay
- Flexible: Aynı event birden fazla iş tetikleyebilir
Request-Reply Pattern
Senkron iletişim gerektiğinde kullanılıyor. NATS bu pattern'i native olarak destekliyor.
Nasıl çalışıyor:
- OrchestratorAgent: "Hey SpotifyAgent, 'jazz' araması yap"
- SpotifyAgent: "Tamam, işte 15 şarkılık liste"
- Timeout ile bekliyor, cevap gelmezse hata döndürüyor
Work Queue Pattern
Birden fazla worker aynı queue'dan iş çekiyor. Otomatik load balancing sağlıyor.
Senaryo: 1000 tane transkripsiyon görevi var, 3 worker işliyor. Her task sadece bir worker'a gidiyor.
Event Streaming
Kafka'nın uzmanlık alanı. Event'ler kalıcı olarak saklanıyor, istediğin zaman replay edebiliyorsun.
Ne zaman lazım:
- Audit trail gerektiğinde
- "Geçen hafta ne olmuştu?" sorusuna cevap vermek istediğinde
- Multiple consumer groups farklı hızlarda işlem yapacaksa
MessageBus Nedir?
MessageBus, agent'lar arasında mesaj iletimini sağlayan ara katman. Bir "posta sistemi" gibi düşünebilirsin.
Temel görevleri:
- Routing: Mesajı doğru alıcıya ilet
- Decoupling: Producer ve Consumer birbirini bilmek zorunda değil
- Buffering: Consumer yavaşsa mesajları beklet
- Reliability: Mesaj kaybını önle
- Scaling: Yük arttıkça consumer sayısını artır
In-Process vs Distributed
In-Process (Tek process içinde):
- Node.js EventEmitter, Python asyncio events, RxJS Subjects
- Çok hızlı, network yok
- Tek process ile sınırlı
Distributed (Birden fazla process/makine):
- NATS, Redis, RabbitMQ, Kafka
- Horizontal scaling, fault tolerance
- Network latency var ama ölçeklenebilir
Popüler Araçlar Karşılaştırması
Şimdi gelelim asıl konuya - hangi araç ne zaman kullanılmalı?
NATS: Hız ve Basitlik Şampiyonu
Öne çıkan özellikleri:
- Sub-millisecond latency (1ms'nin altı!)
- ~15MB tek binary - kurulumu dakikalar sürüyor
- Request-Reply native desteği
- CNCF projesi (Kubernetes ekosistemi)
- JetStream ile persistence
Ne zaman kullan:
- Real-time agent iletişimi
- Microservices arası hafif mesajlaşma
- IoT ve edge computing
- Düşük latency kritik olduğunda
Ne zaman kullanma:
- Büyük mesajlar (>1MB)
- Uzun süreli event storage gerektiğinde
Performans: 10M+ msg/sec, <1ms latency (99th percentile)
Kullanan şirketler: Tinder, Stripe, Rakuten, Ericsson, VMware
Redis Streams: Zaten Redis Kullanıyorsan
Öne çıkan özellikleri:
- Redis'in built-in stream veri yapısı
- Consumer groups desteği
- Cache + Pub/Sub + Streams tek yerde
Ne zaman kullan:
- Zaten Redis kullanıyorsan (yeni dependency ekleme)
- Basit event streaming
- Session state + messaging birlikte
- Prototipleme aşamasında
Ne zaman kullanma:
- Memory > Data size olduğunda (pahalı olur)
- Çok uzun retention gerektiğinde
İpucu: Redis Pub/Sub vs Redis Streams farkı önemli. Pub/Sub fire-and-forget, Streams'de persistence var.
RabbitMQ: Kurumsal Message Queue
Öne çıkan özellikleri:
- AMQP protokolü (standart)
- Flexible routing (exchanges, bindings)
- Dead letter queues
- Management UI
Ne zaman kullan:
- Task/work queue pattern
- Complex routing gerektiğinde
- Priority queues
- Guaranteed delivery önemli olduğunda
Exchange tipleri:
- Direct: Exact routing key match
- Fanout: Tüm queue'lara broadcast
- Topic: Pattern-based routing (*.error, logs.#)
Apache Kafka: Enterprise Event Backbone
Öne çıkan özellikleri:
- Distributed commit log
- Durable storage (configurable retention)
- Partitioning + Replication
- Kafka Streams (stream processing)
- Exactly-once semantics
Ne zaman kullan:
- Event sourcing / audit trail
- High-throughput data pipelines
- Event replay gerektiğinde
- Compliance/audit gereksinimleri
Ne zaman kullanma:
- Küçük sistemler (overkill)
- Sub-millisecond latency gerektiğinde
- Basit request-reply
Kullanan şirketler: LinkedIn, Netflix, Uber, Airbnb, Spotify
Karşılaştırma Özeti
Latency açısından:
- NATS ve Redis: <1ms
- RabbitMQ: 1-5ms
- Kafka: 5-15ms
Throughput açısından:
- NATS: 10M+ msg/sec
- Redis: 1M+ msg/sec
- RabbitMQ: Orta-yüksek
- Kafka: Çok yüksek (GB/sec)
Kurulum zorluğu:
- NATS: Çok kolay
- Redis: Kolay
- RabbitMQ: Orta
- Kafka: Zor
Mimari Pattern'ler
Pattern 1: Simple Pub/Sub
En basit pattern. Küçük sistemler için ideal.
Uygun: 2-5 agent, prototip aşaması
Araç önerisi: Node.js EventEmitter veya NATS
Pattern 2: Orchestrator Pattern
Merkezi bir koordinatör agent var. Orta ölçekli sistemler için.
Akış:
- Event gelir → Orchestrator alır
- Orchestrator hangi agent'ı çağıracağına karar verir
- İlgili agent'a task gönderir
- Sonuç Orchestrator'a döner
Uygun: 5-15 agent, production
Araç önerisi: NATS + Redis (state için)
Pattern 3: Choreography (Event-Driven)
Merkezi orchestrator yok. Agent'lar event'lere tepki veriyor.
Avantaj: Decoupled, her agent bağımsız scale edilebilir
Dezavantaj: Akışı takip etmek zor, debugging zor
Araç önerisi: Kafka (event sourcing ile)
Pattern 4: Event Sourcing + CQRS
Enterprise grade. Tüm event'ler kalıcı log'da saklanıyor.
Write Side: Agent → Command → Validate → Event Store (Kafka)
Read Side: Event → Projector → Read Model (Redis) → Query
Özellikler:
- Event'ler immutable, sadece append
- Herhangi bir ana "replay" ile state rebuild
- Write ve Read ayrı optimize edilebilir
- Audit trail otomatik
Hibrit Mimariler
Gerçek dünyada genellikle tek bir araç yetmiyor. Farklı ihtiyaçlar için farklı araçları kombine etmek gerekiyor.
Neden hibrit?
Farklı ihtiyaçlar, farklı araçlar gerektirir:
- Real-time internal: NATS (sub-ms latency)
- Session state: Redis (in-memory)
- External API: REST/A2A Protocol
- Audit trail: Kafka (event sourcing)
- Task queue: RabbitMQ (work queues)
Tek araç kullanmak = Her şey için çekiç kullanmak
Hibrit Örnek: MessageBus + A2A Protocol
Bu pattern'in güzel bir uygulaması için Spotify A2A Buddy projesine bakabilirsiniz. 5 agent'ın hem MessageBus (dahili iletişim) hem A2A Protocol (harici API) kullanarak nasıl koordineli çalıştığı detaylı olarak anlatılmış.
Ne zaman hangisi?
MessageBus (NATS/Redis):
- Agent↔Agent internal
- WebSocket broadcasts
- Fire-and-forget events
- <1ms latency kritik
A2A Protocol:
- External integrations
- Task state tracking
- Agent discovery
- Cross-org communication
Kod Örnekleri
NATS ile Agent İletişimi (Node.js)
SpeechAgent Örneği
Redis Streams ile Event Bus (Python)
Docker Compose - Tüm Sistemin Kurulumu
Araç Seçim Rehberi
Karar Ağacı
Sisteminizin büyüklüğüne göre:
Küçük (2-5 agent, prototip):
- Tek process mi? → EventEmitter / RxJS
- Multi-process? → Redis Pub/Sub
Orta (5-20 agent, production):
- Real-time kritik mi? → NATS
- Değilse → RabbitMQ
- Zaten Redis kullanıyor musunuz? → Redis Streams
Büyük (20+ agent, enterprise):
- Event sourcing / Audit gerekli mi? → Kafka
- Hem queue hem stream gerekli mi? → Apache Pulsar
- Multi-datacenter? → Kafka veya Pulsar
Senaryoya Göre Öneriler
Hackathon / PoC: Redis Pub/Sub - Hızlı kurulum, zaten biliniyor
Startup MVP: NATS - Basit, hızlı, büyüyünce de yeterli
Real-time chat agents: NATS - Sub-ms latency
E-commerce order processing: RabbitMQ - Reliable delivery, dead letter queues
Financial audit trail: Kafka - Event sourcing, replay, compliance
IoT sensor agents: NATS + Kafka - NATS real-time, Kafka storage
Başlangıç İçin Minimal Stack
Eğer yeni başlıyorsanız:
NATS (messaging) + Redis (state)
- NATS: Agent iletişimi, real-time events
- Redis: Session state, caching, rate limiting
Bu kombinasyon %90 kullanım senaryosunu karşılar. Sonra ihtiyaca göre Kafka veya RabbitMQ ekleyebilirsiniz.
Production Tavsiyeleri
Monitoring Stack
Metrics: Prometheus + Grafana
- Message throughput
- Latency percentiles (p50, p95, p99)
- Queue depths
- Consumer lag
Tracing: OpenTelemetry + Jaeger
- Distributed traces across agents
- Correlation IDs
- Latency breakdown
Logging: ELK Stack veya Loki
- Structured logs (JSON)
- Correlation ID ile filtreleme
Error Handling
Retry with Exponential Backoff: İlk denemede başarısız olunca, artan aralıklarla tekrar dene
Circuit Breaker: Bir servis sürekli fail ediyorsa, geçici olarak istekleri engelle
Dead Letter Queue: İşlenemeyen mesajları ayrı bir queue'ya at, sonra manuel incele
Güvenlik Checklist
- Authentication: Her araç için (NATS token, Redis ACL, Kafka SASL)
- Encryption: TLS for all connections
- Authorization: Topic/queue level permissions
- Network: Internal network only
- Validation: Schema validation, size limits, rate limiting
Sonuç ve Öğrenme Yolu
Önemli Çıkarımlar
Tek araç yok: Farklı ihtiyaçlar farklı araçlar gerektirir. Hibrit mimariler gerçek dünyada yaygın.
Basit başla: NATS + Redis kombinasyonu çoğu senaryo için yeterli. Karmaşıklığı ihtiyaç oldukça ekleyin.
Event-driven düşün: Agent'lar arası iletişimde event-driven mimari, senkron RPC'den daha ölçeklenebilir.
Observability şart: Dağıtık sistemlerde monitoring olmadan debugging imkansız.
Failure'a hazır ol: Retry, circuit breaker, dead letter queue pattern'lerini baştan implement edin.
Öğrenme Yol Haritası
Hafta 1-2: Temeller
- Pub/Sub kavramını öğren
- Node.js EventEmitter ile pratik yap
- NATS kurulumu ve basit örnekler
Hafta 3-4: İlk Multi-Agent Sistem
- 2-3 agent'lık basit sistem kur
- Request-Reply pattern'i dene
- Redis ile state management ekle
Hafta 5-6: Production Patterns
- Error handling patterns
- Monitoring (Prometheus + Grafana)
- Docker Compose ile deployment
Hafta 7-8: İleri Konular
- Kafka ile event sourcing
- A2A Protocol entegrasyonu
- Hibrit mimari implementasyonu
Kaynaklar
Resmi Dokümantasyonlar:
İlgili Makaleler:
Kitaplar:
- "Designing Data-Intensive Applications" - Martin Kleppmann
- "Enterprise Integration Patterns" - Gregor Hohpe