İLERİ

Horizontal Scaling

Tek queue yetmediğinde sistemi nasıl büyütürsün? Sadece sunucu eklemek yetmez — çünkü her queue'nun tek bir "lider" node'u vardır. Gerçek çözüm: işi parçala (sharding) ve her parçaya ayrı consumer'lar bağla.

Seviye: İleri — Sharding ve load balancing deneyimi gerektirir. Clustering ve Node Discovery ile Quorum Queues ve High Availability konularını önce tamamlayın.

📖 Teknik detay: Queue'lar tek bir leader üzerinde çalışır. Node eklemek HA sağlar ama throughput artırmaz. Throughput için: daha fazla queue (sharding) + daha fazla consumer + load balancing gerekir.

Scaling Karar Tablosu

Belirti	Çözüm	Neden Node Eklemek Yetmez
Tek queue'da throughput limiti	Queue sharding (Consistent Hash Exchange veya application-level)	Queue tek leader'da çalışır, node eklemek leader'ı hızlandırmaz
Consumer'lar yetişemiyor	Consumer scale-out + prefetch tuning	Node eklemek consumer sayısını artırmaz
Connection limiti	Node ekle + Load Balancer ile connection dağıt	Bu durumda node ekleme doğru
Memory/Disk pressure	Node ekle + queue leader rebalance	Kaynak dağılımı için node gerekli
HA/fault tolerance artırmak	Node ekle + quorum group size artır	Daha fazla replica için node gerekli

Consistent Hash Exchange (Sharding)

RabbitMQ'nun built-in plugin'i ile mesajları routing key veya header hash'ine göre N queue'ya dengeli dağıtabilirsiniz. Her queue farklı node'da leader olacak şekilde ayarlanırsa gerçek paralel throughput elde edilir.

# Plugin'i aktifleştir
rabbitmq-plugins enable rabbitmq_consistent_hash_exchange

# Exchange declare (type: x-consistent-hash)
rabbitmqadmin declare exchange name=orders-sharded type=x-consistent-hash durable=true

# Shard queue'ları oluştur
rabbitmqadmin declare queue name=orders-shard-0 durable=true arguments='{"x-queue-type":"quorum"}'
rabbitmqadmin declare queue name=orders-shard-1 durable=true arguments='{"x-queue-type":"quorum"}'
rabbitmqadmin declare queue name=orders-shard-2 durable=true arguments='{"x-queue-type":"quorum"}'
rabbitmqadmin declare queue name=orders-shard-3 durable=true arguments='{"x-queue-type":"quorum"}'

# Bind (routing_key = weight, eşit dağılım için aynı değer)
rabbitmqadmin declare binding source=orders-sharded destination=orders-shard-0 routing_key=1
rabbitmqadmin declare binding source=orders-sharded destination=orders-shard-1 routing_key=1
rabbitmqadmin declare binding source=orders-sharded destination=orders-shard-2 routing_key=1
rabbitmqadmin declare binding source=orders-sharded destination=orders-shard-3 routing_key=1

# Publish: routing_key olarak hash'lenecek değeri kullan (örn: order_id)
# Aynı order_id her zaman aynı shard'a gider (ordering guarantee per-key)

frontend rabbitmq_amqp
    bind *:5672
    mode tcp
    default_backend rabbitmq_nodes

backend rabbitmq_nodes
    mode tcp
    balance leastconn
    option tcp-check

    # Health check via HTTP API
    option httpchk GET /api/health/checks/alarms
    http-check expect status 200

    server rabbit1 10.0.1.10:5672 check port 15672 inter 5s fall 3 rise 2
    server rabbit2 10.0.1.11:5672 check port 15672 inter 5s fall 3 rise 2
    server rabbit3 10.0.1.12:5672 check port 15672 inter 5s fall 3 rise 2

frontend rabbitmq_management
    bind *:15672
    mode http
    default_backend rabbitmq_mgmt_nodes

backend rabbitmq_mgmt_nodes
    mode http
    balance roundrobin
    server rabbit1 10.0.1.10:15672 check
    server rabbit2 10.0.1.11:15672 check
    server rabbit3 10.0.1.12:15672 check

Anti-Pattern: Tek Queue ile Scale Etmeye Çalışmak — Bir queue'nun throughput'u tek bir Raft leader tarafından sınırlıdır (~50-100K msg/s). 10 node eklemeniz bu limiti değiştirmez. Gerçek scaling = workload'u birden fazla queue'ya bölmek (sharding).

Gerçek hayat senaryosu: E-ticaret Black Friday: Normal günde 5K order/s, peak'te 50K order/s. Consistent hash exchange ile order_id bazlı 8 shard oluşturulur. Her shard farklı node'da leader. 8 × ~15K = 120K msg/s capacity. Consumer'lar HPA ile peak'te 3x scale-out yapılır.