Dağıtık Sistemlerde İstemci-Sunucu Mimarisi ve İletişim Protokolleri

Bir uygulama tek sunucuda sorunsuz çalışırken neden birkaç servise bölündüğünde timeout, tekrar eden mesaj, bağlantı kopması ve veri tutarsızlığı gibi sorunlarla karşılaşır? Çünkü servis sınırı aşıldığı anda işin içine ağ girer. Ağ ise uygulama içindeki bir fonksiyon çağrısı kadar öngörülebilir değildir.

Dağıtık Sistemlerde İstemci-Sunucu Mimarisi ve İletişim Protokolleri konusu tam olarak bu noktada önem kazanır. Yaklaşık on yıllık backend ve sistem mimarisi deneyiminde gördüğüm en önemli noktalardan biri şu: Doğru protokol seçimi yalnızca performans meselesi değildir. Hata yönetimi, güvenlik, ölçeklenebilirlik, gözlemlenebilirlik ve ekip deneyimi de kararın parçasıdır.

Bu rehberde dağıtık sistemlerde istemci sunucu mimarisi nasıl tasarlanır sorusundan başlayıp HTTP, gRPC, WebSocket, TCP, UDP, QUIC, mesaj kuyrukları, event streaming, API Gateway, servis keşfi, load balancing ve güvenilir iletişim desenlerine kadar uzanan geniş bir çerçeve oluşturacağız.

Dağıtık Sistem Nedir?

Dağıtık sistem, bir görevi yerine getirmek için ağ üzerinden haberleşen birden fazla bağımsız bileşenin birlikte çalıştığı sistemdir. Kullanıcı tek bir uygulama görse bile arka planda farklı servisler, veri depoları ve mesajlaşma bileşenleri bulunabilir.

Tek Process ile Dağıtık Sistem Arasındaki Fark

Tek process içinde fonksiyon çağrısı bellekte gerçekleşir. Dağıtık yapıda ise çağrı ağ üzerinden gider ve karşı sistemin erişilebilir olması gerekir. Bu küçük fark, hata modelini tamamen değiştirir.

Network Neden Yeni Bir Failure Boundary Oluşturur?

Ağ bağlantısı kopabilir, paket gecikebilir veya hedef servis geçici olarak erişilemez olabilir. İstemci isteğin başarısız olduğunu görürken sunucu işlemi tamamlamış bile olabilir. Bu nedenle ağ sınırı yeni bir hata alanıdır.

Dağıtık Sistemlerin Temel Özellikleri

Dağıtık sistemleri anlamanın yolu yalnızca servis sayısına bakmak değildir. Eş zamanlılık, bağımsız hata, gecikme ve kısmi çalışma durumları birlikte değerlendirilmelidir.

Concurrency

Birden fazla servis aynı anda farklı işlemleri yürütür. Aynı veriye eş zamanlı erişim olduğunda yarış koşulları ve tutarlılık sorunları oluşabilir.

Independent Failure

Bir servis çalışırken başka bir servis durabilir. Sistem bileşenlerinin bağımsız hata verebilmesi, hata izolasyonunu önemli hale getirir.

Network Latency

Uzak servise yapılan çağrı hiçbir zaman yerel fonksiyon çağrısı kadar hızlı değildir. Mesafe, ağ yoğunluğu ve bağlantı kurulumu gecikmeye doğrudan etki eder.

Partial Failure

Sistemin bir bölümü çalışırken başka bir bölümü yanıt vermeyebilir. Dağıtık sistem tasarımında en zor senaryolardan biri de budur.

İstemci-Sunucu (Client-Server) Mimarisi Nedir?

İstemci-sunucu mimarisi, hizmet isteyen taraf ile hizmet sağlayan tarafı ayırır. Web tarayıcısının API'ye istek göndermesi bunun en bilinen örneklerinden biridir.

Client'ın Rolü

Client bir işleme ihtiyaç duyar, isteği oluşturur ve uygun sunucuya gönderir. Yanıtı aldıktan sonra kullanıcı arayüzünü güncelleyebilir veya başka bir işleme devam edebilir.

Server'ın Rolü

Server gelen isteği doğrular, gerekli iş mantığını çalıştırır ve yanıt üretir. Gerektiğinde veritabanı veya başka servislerle de iletişime geçer.

Request ve Response

Request, client tarafından gönderilen talebi ifade eder. Response ise server'ın bu talebe verdiği cevaptır. HTTP tabanlı sistemlerde bu model oldukça yaygındır.

Aynı Servis Hem Client Hem Server Olabilir mi?

Evet. Bir servis dışarıdan istek aldığında server, başka bir servise çağrı yaptığında client rolündedir. Mikroservislerde bu durum sürekli görülür.

Client-Server Mimarisi Dağıtık Sistemlere Nasıl Dönüşür?

Tek bir sunucunun yaptığı işler bağımsız servislere ayrıldığında client-server ilişkileri zincir hâline gelir. API servisi sipariş servisine, sipariş servisi ödeme veya stok servisine çağrı yapabilir.

Client-Server ile Peer-to-Peer Arasındaki Fark

Merkezi Server Modeli

Client-server modelinde kaynakların önemli bölümü merkezi veya kontrol edilen sunucu katmanlarında bulunur. Yetkilendirme ve veri yönetimi daha merkezi yürütülebilir.

Peer Modeli

Peer-to-peer modelinde düğümler hem hizmet tüketebilir hem hizmet sağlayabilir. Merkezi bir servis zorunlu değildir.

Resource Ownership

Client-server yaklaşımında kaynak sahipliği genellikle sunucudadır. Peer modelinde kaynak farklı düğümlere dağılabilir.

Discovery

Client-server yapısında DNS veya servis kayıt mekanizmaları kullanılabilir. Peer sistemlerde düğümlerin birbirini keşfetmesi daha farklı yöntemler gerektirebilir.

Failure ve Trust Modeli

Merkezi sistemlerde güven sınırları daha belirgin olabilir. Peer modellerinde her düğümün güven seviyesi ayrıca değerlendirilmelidir.

2-Tier, 3-Tier ve N-Tier Client-Server Mimarileri

2-Tier

2-Tier yapıda istemci doğrudan veri veya uygulama sunucusuyla iletişim kurar.

Client

Kullanıcı arayüzünü ve kimi durumlarda iş mantığının bir bölümünü barındırabilir.

Database / Server

Verinin saklanması ve sorgulanması bu katmanda gerçekleşir.

3-Tier

3-Tier yapı, sunum, uygulama ve veri katmanlarını birbirinden ayırır.

Presentation

Kullanıcıyla etkileşime giren arayüz katmanıdır.

Application

İş kuralları ve uygulama akışları burada yürütülür.

Data

Kalıcı veri yönetiminden sorumludur.

N-Tier

N-Tier yapıda görevler daha fazla bağımsız katmana ayrılır. Büyük ölçekli sistemlerde API erişimi, servisler ve mesajlaşma ayrı bileşenlere dönüşebilir.

API Gateway

Dış istemcilerin sisteme giriş noktasıdır. Routing, kimlik doğrulama ve rate limiting gibi görevleri üstlenebilir.

Services

İş kabiliyetleri bağımsız servislerde yürütülür.

Data Layer

Servislerin ihtiyaç duyduğu veri depolarını kapsar.

Messaging Layer

Asenkron iletişim, event dağıtımı ve background işlemler bu katmanda yürütülebilir.

Dağıtık Sistemlerde İletişim Neden Zordur?

Network Güvenilir Değildir

Bağlantılar kopabilir. Paketler kaybolabilir. DNS geçici hata verebilir. Bu nedenle başarılı bağlantıyı varsaymak doğru değildir.

Latency Sıfır Değildir

Her ağ çağrısının maliyeti vardır. Zincir hâlindeki servis çağrıları toplam gecikmeyi hızla büyütebilir.

Bandwidth Sonsuz Değildir

Büyük payload'lar ağ kapasitesini tüketir. Serileştirme formatı ve veri miktarı performansı doğrudan etkiler.

Topology Değişebilir

Servis instance'ları açılıp kapanabilir. IP adresleri değişebilir. Bu yüzden statik adreslere fazla güvenmek ölçeklenebilirliği azaltır.

Bir Sistem Kısmen Çalışıyor Olabilir

Gateway sağlıklı görünürken bağlı olduğu servislerden biri çalışmayabilir. Kullanıcı açısından ise bütün işlem başarısız olur.

Mesajlar Gecikebilir, Kaybolabilir veya Tekrarlanabilir

Retry politikaları nedeniyle aynı mesaj birden fazla kez işlenebilir. Bu nedenle idempotency tasarımın temel parçalarından biridir.

Protokol, API Stili ve Messaging Pattern Arasındaki Fark

Bu kavramlar sıkça birbirine karıştırılır. Oysa transport protokolü, uygulama protokolü, API stili ve mesajlaşma deseni farklı soruları yanıtlar.

Transport Protocol

TCP

Güvenilir ve sıralı byte stream sağlar.

UDP

Düşük ek yükle connectionless veri gönderimine izin verir.

QUIC

UDP üzerinde çalışan, güvenlik ve modern bağlantı özelliklerini bir araya getiren transport yaklaşımıdır.

Application Protocol

HTTP

Web ve API iletişiminde en yaygın uygulama protokollerinden biridir.

WebSocket

Uzun süre açık kalan çift yönlü bağlantılar sağlar.

MQTT

Özellikle düşük kaynaklı cihazlar ve pub/sub iletişimi için uygundur.

AMQP

Mesaj yönlendirme, kuyruk ve güvenilir teslim ihtiyaçlarında kullanılan uygulama katmanı protokolüdür.

RPC Framework

gRPC

Typed contract, kod üretimi ve streaming özellikleri sunan bir RPC framework'üdür.

API Style

REST

Kaynak odaklı HTTP API tasarım yaklaşımıdır.

GraphQL

Client'ın ihtiyaç duyduğu veri şeklini sorgu üzerinden tanımlamasına imkân verir.

Messaging Pattern

Queue

İşlerin consumer'lar arasında dağıtılmasını sağlar.

Pub/Sub

Bir olayın birden fazla aboneye iletilebilmesini sağlar.

Event Stream

Olayların sıralı ve yeniden okunabilir biçimde saklanmasına odaklanır.

OSI ve TCP/IP Katmanları Bu Kararı Nasıl Etkiler?

Application Layer

HTTP, MQTT ve benzeri protokoller uygulama seviyesinde davranış tanımlar.

Transport Layer

TCP, UDP ve QUIC gibi protokoller uçtan uca veri taşınmasını düzenler.

Network Layer

IP, paketlerin ağlar arasında yönlendirilmesini sağlar.

Protokollerin Katmanlar Üzerindeki İlişkisi

Bir uygulama protokolü çoğu zaman alttaki transport özelliklerinden etkilenir. HTTP/3'ün QUIC kullanması bunun iyi bir örneğidir.

TCP Nedir?

Connection-Oriented Communication

TCP veri aktarımından önce bağlantı kurar.

Reliable Delivery

Kayıp segmentleri yeniden göndererek güvenilir teslim sağlamayı amaçlar.

Ordered Byte Stream

Veriyi gönderildiği sıraya uygun biçimde uygulamaya iletir.

Retransmission

Kayıp veriler gerektiğinde yeniden gönderilir.

Congestion Control

Ağ yoğunluğuna göre gönderim hızını düzenlemeye çalışır.

TCP Ne Zaman Tercih Edilir?

Eksiksiz ve sıralı veri aktarımı gereken veri tabanı bağlantıları, HTTP/1.1, HTTP/2 ve birçok uygulama protokolünde uygundur.

UDP Nedir?

Connectionless Communication

UDP, bağlantı kurulum süreci olmadan datagram gönderir.

Delivery Guarantee Olmaması

Paketin hedefe ulaştığını garanti etmez.

Ordering Guarantee Olmaması

Paketlerin gönderildiği sırada ulaşacağı garanti edilmez.

Düşük Overhead

Bağlantı yönetimi ve güvenilir teslim mekanizmaları daha sınırlı olduğu için ek yük düşüktür.

UDP Ne Zaman Mantıklıdır?

Düşük gecikmenin eksiksiz teslimden daha önemli olduğu gerçek zamanlı medya ve özel iletişim senaryolarında değerlendirilebilir.

QUIC Nedir?

UDP Üzerindeki Modern Transport

QUIC, UDP üzerinde güvenilir stream iletişimi ve modern bağlantı yönetimi sağlar.

TLS Entegrasyonu

Şifreleme bağlantı modelinin temel parçasıdır.

Multiple Streams

Tek bağlantı içinde birden fazla bağımsız stream taşınabilir.

Per-Stream Recovery

Bir stream üzerindeki kayıp, diğer stream'lerin ilerlemesini doğrudan durdurmak zorunda değildir.

Connection Migration

İstemci ağ değiştirirken bağlantının devam ettirilmesini kolaylaştırabilir.

QUIC ile HTTP/3 İlişkisi

HTTP/3 transport katmanında QUIC kullanır.

HTTP Nasıl Çalışır?

Request

Client'ın server'a gönderdiği HTTP mesajıdır.

Method

İsteğin amacını belirtir. GET ve POST buna örnektir.

URL

İstenen kaynağın adresini tanımlar.

Headers

Kimlik doğrulama, içerik tipi ve cache gibi ek bilgiler taşır.

Body

Gerekli durumlarda veri payload'ını içerir.

Response

Status Code

İşlemin sonucunu standart kodlarla ifade eder.

Headers

Yanıt hakkında ek metadata sunar.

Body

Client'a döndürülen veriyi içerir.

Statelessness

HTTP istekleri bağımsız işlenebilir. Uygulama seviyesindeki session yönetimi ayrıca tasarlanır.

Keep-Alive ve Connection Reuse

Aynı bağlantının tekrar kullanılması yeni bağlantı kurma maliyetini azaltır.

HTTP/1.1, HTTP/2 ve HTTP/3 Karşılaştırması

HTTP/1.1

Connection Model

Birden fazla isteği yönetmek için bağlantı tekrar kullanımı veya birden fazla bağlantı gerekebilir.

Pipelining Sınırları

Pipelining teorik fayda sağlasa da uygulamadaki sınırlamaları nedeniyle geniş kullanım görmemiştir.

HTTP/2

Binary Framing

HTTP mesajlarını binary frame'lere böler.

Multiplexing

Aynı TCP bağlantısı üzerinden eş zamanlı birden fazla stream taşınabilir.

Header Compression

Tekrarlanan header verisinin ağ maliyetini azaltır.

HTTP/3

QUIC

TCP yerine QUIC kullanır.

Independent Streams

Stream'ler transport seviyesinde daha bağımsız ilerleyebilir.

Faster Connection Establishment

Bağlantı ve güvenlik kurulumu daha az round trip ile tamamlanabilir.

Network Migration

Mobil cihazların ağ değiştirdiği senaryolarda bağlantı sürekliliğine katkı sağlayabilir.

Head-of-Line Blocking Nedir?

TCP Seviyesinde Blocking

TCP sıralı teslim sağladığı için kayıp bir segment, arkasındaki verilerin uygulamaya teslimini geciktirebilir.

HTTP/2 Üzerindeki Etkisi

HTTP/2 farklı stream'leri multiplex etse de hepsi aynı TCP bağlantısını paylaşır.

QUIC'in Yaklaşımı

QUIC, kaybı stream seviyesinde izole ederek diğer stream'lerin ilerlemesini mümkün kılar.

REST Nedir?

REST Bir Protokol müdür?

Hayır. REST bir mimari stildir. Çoğu REST API HTTP üzerinde uygulanır.

Resource-Oriented Design

API tasarımı kullanıcı, sipariş veya ürün gibi kaynaklar etrafında şekillenir.

HTTP Method Semantiği

GET

Kaynak okumak için kullanılır.

POST

Yeni işlem veya kaynak oluşturma için yaygındır.

PUT

Kaynağın tamamını belirli bir temsil ile güncellemek için kullanılabilir.

PATCH

Kısmi güncelleme işlemlerine uygundur.

DELETE

Kaynak silme niyetini ifade eder.

Stateless API

Her request gerekli bağlamı taşıyabilir. Bu yaklaşım yatay ölçeklemeyi kolaylaştırır.

REST Ne Zaman İyi Bir Seçimdir?

Public API, tarayıcı entegrasyonu, CRUD operasyonları ve kolay debug edilebilirlik gerektiğinde güçlü bir seçenektir.

REST'in Avantajları ve Sınırları

Browser Uyumluluğu

Tarayıcılarla doğal biçimde çalışır.

İnsan Tarafından Okunabilirlik

JSON tabanlı REST API'leri geliştiricilerin incelemesi kolaydır.

HTTP Cache

Doğru tasarlandığında HTTP cache mekanizmalarından yararlanabilir.

Tooling

Test, dokümantasyon ve gözlemleme araçları geniştir.

JSON Overhead

Metin tabanlı veri, binary formatlara göre daha büyük payload üretebilir.

Request-Response Sınırlaması

Yoğun streaming veya çift yönlü sürekli iletişim gereken senaryolarda başka modeller daha uygun olabilir.

RPC Nedir?

Local Function Call ile Remote Procedure Call Farkı

Remote call ağdan geçtiği için latency, timeout ve bağlantı hataları devreye girer.

Network Failure'ın RPC Semantiğine Etkisi

Timeout alınması işlemin sunucuda kesinlikle çalışmadığı anlamına gelmez. Retry kararı bu nedenle dikkatli verilmelidir.

RPC'de Contract

İstemci ve sunucunun metot, parametre ve veri tipleri üzerinde ortak sözleşmeye sahip olması gerekir.

gRPC Nedir?

Protocol Buffers

gRPC çoğunlukla Protocol Buffers ile şema tanımlaması ve binary serialization kullanır.

HTTP/2

gRPC iletişimi HTTP/2'nin multiplexing ve streaming özelliklerinden yararlanır.

Generated Client/Server Stubs

Contract dosyasından istemci ve sunucu kodları üretilebilir.

Strongly Typed Contracts

Tip hatalarının daha geliştirme aşamasında görünmesine katkı sağlar.

Internal Service Communication

Servisler arası yüksek hacimli ve typed iletişimde sık tercih edilir.

gRPC İletişim Türleri

Unary RPC

Bir request ve bir response modelidir.

Server Streaming

Client tek istek gönderir, server birden fazla mesaj döndürür.

Client Streaming

Client birden fazla mesaj gönderir, server sonunda tek yanıt üretir.

Bidirectional Streaming

Her iki taraf aynı bağlantı üzerinde bağımsız biçimde mesaj gönderebilir.

gRPC Deadline ve Cancellation

Request Deadline

Çağrının ne kadar sürede tamamlanması gerektiğini sınırlar.

Cascading Cancellation

Üst çağrı iptal edildiğinde alt servis çağrıları da iptal edilebilir.

Gereksiz Downstream İşlemleri Durdurmak

Client artık sonucu beklemiyorsa kaynak tüketmeye devam eden işlemler sonlandırılabilir.

Latency Budget ile Deadline İlişkisi

Toplam kullanıcı gecikmesi hedefi servis çağrılarına bütçe olarak dağıtılmalıdır.

REST mi gRPC mi?

Dağıtık sistemlerde HTTP gRPC WebSocket ve TCP protokolleri karşılaştırması yapılırken tek bir kazanan aramak doğru değildir. Kullanım bağlamı belirleyicidir.

Public API

REST geniş ekosistem ve kolay tüketim nedeniyle çoğu public API için güçlü bir varsayılandır.

Internal API

gRPC typed contract ve performans avantajları nedeniyle servisler arası iletişimde öne çıkabilir.

Browser Clients

REST doğrudan tarayıcı desteğinde daha rahattır.

Mobile Clients

Hem REST hem gRPC kullanılabilir. Payload boyutu ve ağ geçişleri değerlendirilmelidir.

High-Throughput RPC

gRPC binary serialization ve bağlantı tekrar kullanımıyla güçlü bir adaydır.

Debugging

REST ve JSON genellikle elle inceleme açısından daha kolaydır.

Streaming

gRPC birden fazla streaming modeli sunar.

Contract Yönetimi

gRPC schema-first yaklaşımıyla daha sıkı sözleşme yönetimi sağlar.

REST + gRPC Hibrit Mimari

External REST API

Dış istemciler HTTP ve JSON tabanlı REST API üzerinden sisteme erişebilir.

Internal gRPC

Gateway arkasındaki servisler kendi aralarında gRPC kullanabilir.

Protocol Translation Gateway

Gateway dışarıdan gelen REST çağrısını internal gRPC çağrısına çevirebilir.

Tek Contract'tan Farklı API Surface'leri

Uygun tooling ile ortak domain sözleşmelerinden farklı dış arayüzler üretilebilir.

Hibrit Modelin Operasyonel Maliyeti

İki iletişim yaklaşımını desteklemek monitoring, debugging ve ekip bilgi yükünü artırır. Bu maliyet baştan hesaba katılmalıdır.

GraphQL Dağıtık İletişimde Nerede Konumlanır?

GraphQL Bir Transport Protokolü müdür?

Hayır. GraphQL bir sorgu dili ve API çalışma modelidir.

Client-Defined Data Shape

Client yalnızca ihtiyaç duyduğu alanları isteyebilir.

BFF / Aggregation Layer

GraphQL, birden fazla backend kaynağını client için bir araya getiren aggregation katmanında etkili olabilir.

REST/gRPC Backend Üzerinde GraphQL

GraphQL resolver'ları arka planda REST veya gRPC servislerini çağırabilir.

N+1 ve Backend Fan-Out Riski

Kontrolsüz resolver tasarımı çok sayıda backend çağrısına neden olabilir.

Senkron İletişim Nedir?

Request-Response

Caller bir istek gönderir ve yanıt bekler.

Immediate Result

Sonuç akışın devamı için hemen gerekiyorsa senkron model uygundur.

Temporal Coupling

İki tarafın aynı anda erişilebilir olması gerekir.

Cascading Failure Riski

Bir downstream servis yavaşladığında üst servisler de etkilenebilir.

Hangi İşlemlerde Kullanılmalı?

Kimlik doğrulama, anlık fiyat sorgusu veya kullanıcının cevabı hemen beklediği işlemler örnek verilebilir.

Async I/O ile Asenkron İletişim Aynı Şey midir?

Non-Blocking I/O

Async I/O, thread'i bekletmeden I/O işlemi yürütme tekniğidir.

Architectural Synchrony

Kod async olsa bile sistem mimarisi request-response nedeniyle senkron kalabilir.

HTTP Client Örneği

Async HTTP client kullanmak, yanıt bekleme zorunluluğunu ortadan kaldırmaz.

Message Broker Örneği

Broker'a mesaj bırakıp işlemin daha sonra consumer tarafından yürütülmesi mimari olarak asenkron iletişimdir.

Asenkron İletişim Nedir?

Producer

Mesajı veya eventi üretir.

Broker

Mesajı taşıyan ve gerektiğinde saklayan altyapıdır.

Consumer

Mesajı işleyen bileşendir.

Temporal Decoupling

Producer ve consumer'ın aynı anda çalışıyor olması zorunlu değildir.

Failure Isolation

Consumer geçici olarak kapalı olduğunda mesaj broker üzerinde bekleyebilir.

Eventual Processing

İşlem hemen değil, belirli bir gecikmeyle tamamlanabilir.

Senkron mu Asenkron mu?

Caller Sonuca Devam Etmeden Önce İhtiyaç Duyuyor mu?

Evet ise senkron model daha doğal olabilir.

Consumer Offline Olabilir mi?

Olabilmesi gerekiyorsa broker tabanlı asenkron tasarım avantaj sağlar.

İşlem Fan-Out Gerektiriyor mu?

Aynı olay birden fazla consumer'a gidecekse pub/sub veya event streaming uygundur.

Eventual Consistency Kabul Edilebilir mi?

Kabul ediliyorsa servisleri birbirinden ayırmak daha kolaylaşır.

Latency Hedefi Nedir?

Kullanıcı sonucunu anında görmeli mi, yoksa birkaç saniyelik gecikme kabul edilebilir mi? Kararı bu soru belirleyebilir.

Message Queue Nedir?

Producer

İşlenmesi gereken işi mesaj olarak kuyruğa gönderir.

Queue

Mesajları consumer hazır olana kadar tutar.

Consumer

Kuyruktan aldığı mesajı işler.

Acknowledgement

Consumer mesajın başarıyla işlendiğini broker'a bildirir.

Visibility / Lock

İşlenmekte olan mesajın başka consumer tarafından aynı anda alınmasını sınırlayan mekanizmalar kullanılabilir.

Background Job Kullanımı

E-posta gönderimi, rapor üretimi ve dosya işleme gibi görevler kuyruklarla ayrıştırılabilir.

Point-to-Point Messaging

Bir Mesajın Tek Logical Consumer Tarafından İşlenmesi

Aynı iş bir consumer instance tarafından tamamlanır.

Competing Consumers

Birden fazla consumer aynı kuyruktan iş alarak yükü paylaşır.

Work Queue

Arka plan işlerinin dağıtılmasını kolaylaştırır.

Horizontal Scaling

Yük arttığında consumer sayısı artırılabilir.

Publish/Subscribe Nedir?

Publisher

Olayı yayınlayan bileşendir.

Topic

Olayların mantıksal olarak yayımlandığı kanaldır.

Subscriber

İlgilendiği topic'i dinleyen consumer'dır.

Bir Event Birden Fazla Consumer

Aynı olay bağımsız sistemlere gönderilebilir.

Producer-Consumer Decoupling

Producer consumer'ların kim olduğunu bilmek zorunda değildir.

Event Streaming Nedir?

Append-Only Log

Event'ler genellikle log yapısına sıralı biçimde eklenir.

Partition

Veri ölçeklenebilir işleme için bölümlere ayrılır.

Offset

Consumer'ın stream üzerinde hangi noktaya kadar ilerlediğini gösterir.

Consumer Group

Partition'lar consumer instance'ları arasında dağıtılabilir.

Retention

Event'ler belirli süre veya boyut politikasına göre saklanabilir.

Replay

Consumer geçmiş event'leri yeniden okuyabilir.

Message Queue ile Event Stream Arasındaki Fark

Task Distribution

Queue modeli iş dağıtımına odaklanır.

Event History

Event stream geçmiş olayları saklama konusunda daha güçlüdür.

Replay

Event streaming sistemlerinde geçmiş veriyi yeniden tüketmek temel yeteneklerden biridir.

Multiple Consumers

Farklı consumer grupları aynı event geçmişini bağımsız okuyabilir.

Ordering

Sıralama çoğu sistemde partition seviyesinde garanti edilir.

Retention

Queue'da mesaj işlendiğinde kaldırılabilirken stream yaklaşımında retention politikasına göre saklanabilir.

Command ve Event Arasındaki Fark

Command: Bir Şey Yap

Command belirli bir eylemin gerçekleştirilmesini ister.

Event: Bir Şey Oldu

Event geçmişte gerçekleşmiş bir durumu bildirir.

Naming Convention

Command adları eylem, event adları gerçekleşmiş durum şeklinde ifade edilmelidir.

Ownership

Command genellikle belirli bir owner'a yönelir. Event ise ilgilenen birçok consumer tarafından tüketilebilir.

Coupling Üzerindeki Etkisi

Event tabanlı yaklaşım producer'ı belirli consumer'lardan daha fazla ayırabilir.

Kafka Hangi Probleme Uygundur?

Event Streaming

Yüksek hacimli olay akışlarının saklanması ve dağıtılması için uygundur.

High Throughput

Büyük mesaj hacimlerini verimli şekilde işlemek üzere tasarlanmıştır.

Replay

Geçmiş event'ler offset üzerinden yeniden okunabilir.

Consumer Groups

İş yükü consumer instance'ları arasında paylaşılabilir.

Kafka'yı Sıradan Queue Gibi Kullanmamak

Kafka'nın güçlü olduğu retention, replay ve stream işleme özelliklerinden yararlanılmayacaksa daha basit bir queue çözümü yeterli olabilir.

RabbitMQ ve AMQP

Queue

Mesajların consumer'lara güvenilir şekilde aktarılmasını sağlar.

Exchange

Mesajları routing kurallarına göre uygun queue'lara yönlendirir.

Routing

Routing key ve exchange türleri farklı teslim modelleri oluşturur.

Acknowledgement

Mesajın işlenip işlenmediğini takip etmeye yardımcı olur.

Dead Letter Queue

Başarısız mesajlar inceleme veya yeniden işleme için ayrı kuyruğa yönlendirilebilir.

Enterprise Messaging

Kurumsal entegrasyonlarda gelişmiş routing ve mesaj teslim ihtiyaçlarını karşılayabilir.

MQTT

Lightweight Pub/Sub

Düşük bant genişliği ve sınırlı cihaz kaynakları için uygun pub/sub modelidir.

Broker

Publisher ve subscriber arasındaki mesaj akışını yönetir.

Topics

Mesajlar topic isimleri üzerinden organize edilir.

IoT Use Case

Sensör, cihaz telemetrisi ve uzaktan kontrol senaryolarında yaygın olarak değerlendirilir.

QoS 0

Mesaj en fazla bir kez gönderilir ve teslim garantisi yoktur.

QoS 1

Mesajın en az bir kez teslim edilmesi hedeflenir, duplicate oluşabilir.

QoS 2

Daha güçlü teslim koordinasyonu sağlar ancak ek protokol maliyeti oluşturur.

WebSocket Nedir?

HTTP Upgrade / Connection Establishment

Bağlantı HTTP üzerinden başlatılıp WebSocket iletişimine geçirilebilir.

Persistent Connection

Bağlantı tek request sonrasında kapanmaz, açık tutulur.

Full-Duplex Communication

Client ve server bağımsız biçimde veri gönderebilir.

Text ve Binary Frames

Hem metin hem binary mesaj taşınabilir.

WebSocket Ne Zaman Kullanılmalı?

Kullanıcı ile sunucu arasında sürekli ve çift yönlü gerçek zamanlı iletişim gerekiyorsa uygundur.

WebSocket Kullanım Alanları

Chat

Mesajların iki yönde hızlı aktarılmasını sağlar.

Multiplayer

Oyuncu hareketlerinin düşük gecikmeyle paylaşılmasına yardımcı olabilir.

Collaborative Editing

Birden fazla kullanıcının aynı belge üzerinde yaptığı değişiklikleri anlık aktarabilir.

Trading

Fiyat ve emir güncellemelerinin hızlı iletilmesi gereken sistemlerde kullanılabilir.

Interactive Realtime Control

Kullanıcı komutlarının sunucuya ve durum bilgisinin kullanıcıya sürekli akması gereken uygulamalara uygundur.

WebSocket Ölçekleme Problemleri

Çok Sayıda Persistent Connection

Her açık bağlantı sunucu kaynağı tüketir.

Connection Routing

Bir client'ın hangi server instance'ına bağlı olduğunun yönetilmesi gerekir.

Multi-Server Fan-Out

Bir mesajın farklı server'lardaki client'lara ulaştırılması için ortak messaging katmanı gerekebilir.

Reconnection

Bağlantı kopunca yeniden bağlanma ve kaçırılan mesajları telafi etme stratejisi tasarlanmalıdır.

Presence State

Hangi kullanıcının çevrim içi olduğunun dağıtık ortamda tutulması ek koordinasyon gerektirir.

Server-Sent Events (SSE) Nedir?

EventSource

Tarayıcıdaki EventSource API, sunucudan sürekli event akışını tüketebilir.

Server → Client Stream

İletişim temel olarak sunucudan client'a tek yönlüdür.

HTTP-Based Communication

HTTP altyapısı üzerinde çalışır.

Automatic Reconnection

Tarayıcı bağlantı koptuğunda otomatik yeniden bağlanma davranışı sunar.

UTF-8 Event Stream

SSE veri akışı UTF-8 metin formatını kullanır.

SSE Kullanım Alanları

Notifications

Sunucudan kullanıcıya tek yönlü bildirim göndermek için uygundur.

Live Feed

Sürekli güncellenen içerik akışlarında kullanılabilir.

Progress Updates

Uzun süren işlemlerin ilerleme bilgisini aktarabilir.

Monitoring

Dashboard güncellemelerinde basit server push çözümü sağlayabilir.

AI Token Streaming

Metnin parça parça kullanıcıya aktarılması gereken token streaming senaryolarında kullanılabilir.

WebSocket mı SSE mi?

Tek Yönlü Stream → SSE

Yalnızca server'dan client'a canlı veri gerekiyorsa SSE daha basit olabilir.

Çift Yönlü Stream → WebSocket

Her iki taraf sürekli mesaj gönderecekse WebSocket uygundur.

Binary Data

Binary frame ihtiyacında WebSocket daha avantajlıdır.

Reconnect

SSE tarayıcı tarafında otomatik reconnect desteği sunar.

Infrastructure Complexity

Tek yönlü veri için WebSocket kullanmak gereksiz bağlantı yönetimi yükü oluşturabilir.

Polling, Long Polling, SSE ve WebSocket

Short Polling

Client belirli aralıklarla sunucuya yeni veri olup olmadığını sorar.

Long Polling

Server yeni veri gelene kadar request'i bir süre açık tutar.

Server Push

SSE ile server, bağlantı açıkken yeni verileri client'a gönderebilir.

Persistent Duplex Connection

WebSocket iki yönlü sürekli bağlantı sağlar.

Complexity Basamakları

İhtiyaç arttıkça polling'den persistent duplex bağlantıya geçmek mümkündür. En basit yeterli çözüm tercih edilmelidir.

WebTransport Nedir?

HTTP/3 Üzerinde Client-Server Communication

WebTransport, HTTP/3 ve QUIC yeteneklerinden yararlanarak tarayıcı ile server arasında gelişmiş iletişim sağlar.

Bidirectional Streams

İki yönlü güvenilir stream'ler oluşturulabilir.

Unidirectional Streams

Tek yönlü bağımsız stream'ler desteklenir.

Datagrams

Her mesaj için güvenilir teslim zorunlu olmadığında datagram kullanılabilir.

Reliable ve Unreliable Delivery

Aynı iletişim oturumunda farklı teslim ihtiyaçlarına uygun seçenekler sunabilir.

WebTransport mı WebSocket mı?

Single Stream vs Multiple Streams

WebSocket mesajları tek bağlantı akışı üzerinden taşırken WebTransport çoklu stream yaklaşımı sunar.

TCP vs QUIC

WebSocket yaygın olarak TCP tabanlı bağlantı kullanırken WebTransport QUIC üzerinde çalışır.

Reliable Streams

WebTransport güvenilir stream iletişimi sunabilir.

Unreliable Datagrams

Düşük gecikmeli ve kaybı tolere edebilen veriler datagram ile gönderilebilir.

Browser Compatibility

WebSocket desteği daha geniştir. WebTransport seçerken hedef tarayıcı desteği mutlaka kontrol edilmelidir.

Gaming ve Low-Latency Use Case'leri

Çoklu stream ve datagram ihtiyacı olan etkileşimli uygulamalarda WebTransport değerlendirilebilir.

Webhook Nedir?

HTTP Callback

Bir sistemde olay gerçekleştiğinde diğer sisteme HTTP isteği gönderilir.

Producer

Olayı algılayan ve callback'i gönderen taraftır.

Consumer Endpoint

Webhook isteğini kabul eden HTTP endpoint'idir.

Third-Party Integration

Farklı sistemlerin olay tabanlı biçimde entegre edilmesini sağlar.

Polling Alternatifi

Client'ın sürekli durum sorgulaması yerine değişiklik olduğunda bildirim alınabilir.

Güvenilir Webhook Tasarımı

Signature Verification

Webhook'un gerçekten beklenen kaynaktan geldiği imza doğrulamasıyla kontrol edilmelidir.

Retry

Geçici hatalarda kontrollü retry uygulanabilir.

Idempotency

Aynı webhook tekrar geldiğinde business side effect yalnızca bir kez uygulanmalıdır.

Duplicate Handling

Event ID veya idempotency anahtarıyla tekrar mesajlar ayırt edilebilir.

Timeout

Consumer endpoint için kısa ve net timeout sınırları kullanılmalıdır.

Delivery Logs

Gönderim denemeleri, yanıt kodları ve hata bilgileri takip edilmelidir.

Veri Serileştirme Formatları

JSON

İnsan tarafından okunabilir ve web ekosisteminde yaygındır.

Protocol Buffers

Şema tabanlı binary serialization sunar.

Avro

Şema odaklı event ve veri işleme sistemlerinde kullanılabilir.

MessagePack

JSON benzeri veri modelini daha kompakt binary biçimde temsil eder.

CBOR

Küçük payload ve cihaz iletişiminde değerlendirilebilen binary formattır.

JSON mı Binary Format mı?

Debuggability

JSON doğrudan okunabildiği için debug kolaylığı sağlar.

Payload Size

Binary formatlar çoğu durumda daha küçük payload üretebilir.

CPU Cost

Serialization maliyeti kullanılan format ve runtime'a göre ölçülmelidir.

Schema

Binary formatların önemli bölümü açık şema yaklaşımıyla çalışır.

Ecosystem Support

Public entegrasyonlarda yaygın araç desteği bazen ham performanstan daha değerlidir.

Schema-First Communication

Protobuf

RPC sözleşmelerini tip güvenli biçimde tanımlayabilir.

OpenAPI

HTTP API endpoint, request ve response modellerini belgelemek için kullanılır.

AsyncAPI

Event ve mesaj tabanlı sistemlerin sözleşmelerini tanımlamaya yardımcı olur.

Avro Schema

Event verilerinin alanlarını ve veri tiplerini belirler.

JSON Schema

JSON payload yapısını doğrulamak ve belgelemek için kullanılabilir.

Schema Evolution

Backward Compatibility

Yeni producer veya servis sürümünün eski consumer'larla çalışabilmesi hedeflenir.

Forward Compatibility

Eski bileşenlerin yeni şema ile gelen verilerin en azından desteklenen bölümünü işleyebilmesi amaçlanır.

Additive Changes

Yeni optional alan eklemek genellikle en güvenli değişikliklerden biridir.

Field Removal

Alan kaldırmadan önce tüm consumer'ların kullanım durumu doğrulanmalıdır.

Consumer Upgrade Window

Dağıtık sistemlerde tüm consumer'ların aynı anda güncellenmeyeceği varsayılmalıdır.

Delivery Semantics

At-Most-Once

Mesaj en fazla bir kez işlenir ancak kaybolabilir.

At-Least-Once

Mesajın en az bir kez işlenmesi hedeflenir, duplicate olasılığı vardır.

Exactly-Once İddiasının Sınırları

Transport seviyesinde exactly-once yaklaşımı, veritabanı veya dış sistemdeki business side effect'in otomatik olarak tek sefer gerçekleştiği anlamına gelmez.

Business Side Effect ile Transport Delivery Farkı

Mesajın bir kez teslim edilmesi ile para çekme, sipariş oluşturma veya e-posta gönderme gibi etkinin bir kez uygulanması farklı konulardır.

Idempotency

Idempotent Request

Aynı request birden fazla kez geldiğinde sonuç istenmeyen biçimde değişmez.

Idempotency Key

Client'ın ürettiği benzersiz anahtar, tekrar istekleri tanımaya yardımcı olabilir.

Duplicate Message

At-least-once sistemlerde duplicate mesaj normal bir olasılık olarak ele alınmalıdır.

Payment ve Order Senaryoları

Aynı ödeme talebinin iki kez ücretlendirmeye dönüşmemesi idempotency'nin en kritik örneklerinden biridir.

Message Ordering

Global Ordering

Tüm mesajlar için global sıra sağlamak pahalı olabilir ve ölçeklenebilirliği sınırlayabilir.

Partition Ordering

Birçok event sistemi sıralamayı partition içinde garanti eder.

Aggregate-Level Ordering

Sipariş ID gibi aynı aggregate'a ait event'leri aynı partition'a yönlendirmek anlamlı bir sıra sağlayabilir.

Out-of-Order Message Handling

Consumer eski event'i fark edebilmeli veya versiyon kontrolü uygulayabilmelidir.

Dead Letter Queue

Retry Limit

Belirli sayıda başarısız denemeden sonra mesaj ayrı kuyruğa alınabilir.

Poison Message

Sürekli hata üreten mesaj normal iş akışını tıkamamalıdır.

Inspection

Başarısız mesajların nedeni ve payload'ı incelenebilmelidir.

Replay

Sorun giderildikten sonra mesaj yeniden işlenebilir.

Manual Recovery

Bazı kritik olaylarda kontrollü insan müdahalesi gerekebilir.

Backpressure ve Flow Control

Fast Producer / Slow Consumer

Producer consumer'dan hızlıysa sistemde birikme oluşur.

Queue Growth

Queue derinliği kontrolsüz büyüyorsa kapasite veya trafik yönetimi sorunu vardır.

Streaming Flow Control

Receiver'ın işleme kapasitesi sender'a iletilebilir.

Consumer Capacity

Consumer concurrency sınırları gerçek CPU, I/O ve dependency kapasitesine göre belirlenmelidir.

Load Shedding

Sistem kapasitesini aştığında düşük öncelikli trafiği reddetmek genel sağlığı koruyabilir.

Timeout Stratejisi

Connection Timeout

Bağlantı kurulumunun ne kadar bekleneceğini belirler.

Request Timeout

İşlemin tamamlanması için maksimum süre tanımlar.

Stream Idle Timeout

Uzun süre veri akmayan stream'lerin ne zaman kapatılacağını belirler.

Latency Budget

Toplam response süresi için ayrılan zaman downstream çağrılara bilinçli dağıtılmalıdır.

Fail Fast

Başarısız olacağı açık bir çağrıyı gereksiz yere uzun süre bekletmemek kaynakları korur.

Retry Stratejisi

Retryable Errors

Geçici bağlantı hataları veya kısa süreli servis erişimsizliği retry için uygun olabilir.

Non-Retryable Errors

Validation hatası gibi kalıcı hataları tekrar denemek fayda sağlamaz.

Exponential Backoff

Her deneme arasındaki süre kademeli artırılır.

Jitter

Client'ların aynı anda yeniden deneme yapmasını önlemek için bekleme süresine rastgelelik eklenir.

Retry Budget

Sonsuz retry yerine toplam deneme sayısı ve süre sınırı belirlenmelidir.

Retry Storm

Yoğun hata döneminde binlerce client'ın tekrar deneme yapması zaten zorlanan servisi daha fazla yükleyebilir.

Circuit Breaker

Closed

Çağrılar normal biçimde downstream servise gider.

Open

Hata eşiği aşıldığında çağrılar kısa süreliğine engellenir.

Half-Open

Servisin iyileşip iyileşmediğini kontrol etmek için sınırlı test çağrıları gönderilir.

Fallback

Uygunsa cache, varsayılan cevap veya sınırlı fonksiyon sağlanabilir.

Cascading Failure Önleme

Arızalı servise sürekli trafik göndermemek sistemin diğer bölümlerini korur.

Bulkhead Pattern

Resource Isolation

Farklı iş yükleri ayrı kaynak havuzlarında çalıştırılabilir.

Connection Pool Isolation

Bir dependency'nin bağlantı tüketimi diğer dependency'leri etkilememelidir.

Worker Pool Isolation

Yoğun bir iş türü tüm worker kapasitesini tüketmemelidir.

Failure Containment

Bir alandaki sorun mümkün olduğunca o alanla sınırlandırılır.

Service Discovery

Static Addresses

Küçük ve değişmeyen sistemlerde işe yarayabilir ancak dinamik ortamlarda yönetimi zordur.

DNS-Based Discovery

Servis isimleri DNS aracılığıyla uygun adreslere çözümlenebilir.

Service Registry

Aktif servis instance'ları merkezi veya dağıtık bir kayıt sisteminde tutulabilir.

Client-Side Discovery

Client uygun instance'ı kendisi seçer.

Server-Side Discovery

Client ortak endpoint'e bağlanır, routing aracı uygun instance'a yönlendirir.

Load Balancing

Round Robin

İstekler instance'lara sırayla dağıtılır.

Least Connections

Daha az aktif bağlantısı olan instance tercih edilir.

Latency-Aware

Daha hızlı yanıt veren sağlıklı instance'lara öncelik verilebilir.

Consistent Hashing

Belirli key'lerin aynı backend grubuna yönlendirilmesini kolaylaştırır.

Health Checks

Sağlıksız instance'ların trafik havuzundan çıkarılması gerekir.

Reverse Proxy, API Gateway ve BFF

Reverse Proxy

Client ile backend arasında proxy görevi görür ve trafik yönlendirebilir.

API Gateway

Client-server iletişiminde API gateway load balancing ve servis keşfi nasıl uygulanır sorusu, dağıtık sistem tasarımında sık karşıma çıkar. Gateway dış trafik için merkezi politika noktası olabilir, load balancer sağlıklı instance'lara trafik dağıtır, service discovery ise değişen servis adreslerini çözer.

Routing

İstekleri path, host veya başka kurallara göre uygun servise yönlendirir.

Authentication

Dış istemcinin kimliği gateway seviyesinde doğrulanabilir.

Rate Limiting

Client başına trafik sınırları uygulanabilir.

Backend for Frontend

BFF, belirli client türünün ihtiyaçlarına uygun backend yüzeyi sunar.

Browser BFF

Web arayüzünün ihtiyaç duyduğu veri ve çağrıları optimize eder.

Mobile BFF

Mobil bağlantı, payload ve ekran akışlarına uygun API sunabilir.

API Gateway ile Message Broker Arasındaki Fark

Request-Response Trafiği

API Gateway daha çok senkron request-response trafiğinin giriş noktasında kullanılır.

Async Messaging

Message broker producer ve consumer'ı zaman açısından birbirinden ayırır.

External Edge

Gateway dış istemciler ile internal servisler arasındaki sınırda konumlanabilir.

Internal Workflow

Broker internal background işlerini ve event akışlarını taşıyabilir.

Service Mesh

East-West Traffic

Servisler arasındaki internal trafiği yönetmeye odaklanır.

mTLS

Servisler arası karşılıklı kimlik doğrulamalı şifreli bağlantı sağlayabilir.

Routing

Internal trafik politikaları merkezi olarak uygulanabilir.

Retry

Belirli retry davranışları proxy katmanında yönetilebilir.

Circuit Breaking

Sağlıksız servislere trafiği sınırlayan politikalar uygulanabilir.

Telemetry

Servis trafiği için ortak metric ve trace verisi sağlanabilir.

Service Mesh Ne Zaman Fazla Karmaşıktır?

Az sayıda servisi olan ve gelişmiş trafik politikalarına ihtiyaç duymayan ekiplerde ek proxy ve kontrol katmanı gereksiz operasyonel yük oluşturabilir.

North-South ve East-West Communication

External Client Trafiği

Dış kullanıcı veya uygulamalardan sisteme gelen trafik north-south olarak değerlendirilir.

Internal Service Trafiği

Servisler arasındaki trafik east-west iletişimdir.

Farklı Protokol Kullanma Stratejisi

Dışarıda REST, içeride gRPC ve event akışında mesajlaşma kullanmak oldukça doğal bir hibrit yaklaşımdır.

Dağıtık Sistemlerde İletişim Güvenliği

TLS

Client ile server arasındaki veriyi şifreler ve sunucu kimliğinin doğrulanmasına yardımcı olur.

mTLS

Her iki tarafın sertifika ile birbirini doğrulamasını sağlar.

OAuth 2.0

Yetkilendirme akışları için yaygın bir standarttır.

JWT

Kimlik ve yetki claim'lerini taşımak için kullanılabilir.

API Key

Basit servis veya partner erişimlerinde kullanılabilir ancak tek başına kapsamlı yetkilendirme modeli değildir.

Workload Identity

Servis kimliklerinin statik secret yerine platform kimliğiyle yönetilmesine yardımcı olur.

Authentication ve Authorization Ayrımı

Client Kim?

Authentication, isteği yapanın kimliğini doğrular.

Service Kim?

Servisler arası iletişimde workload kimliği de doğrulanmalıdır.

Hangi Resource'a Erişebilir?

Authorization, doğrulanmış kimliğin hangi işlemleri yapabileceğini belirler.

User Context Propagation

Kullanıcı bağlamı servisler arasında taşınırken güvenli ve kontrollü biçimde aktarılmalıdır.

API Rate Limiting

Per Client

Her API client için bağımsız trafik limiti uygulanabilir.

Per User

Kullanıcı bazında kötüye kullanım ve aşırı kaynak tüketimi kontrol edilebilir.

Per Service

Internal servis çağrıları için de kapasite sınırları tanımlanabilir.

Token Bucket

Belirli hızda token üreterek kısa süreli burst trafiğine kontrollü izin verir.

Backpressure ile Rate Limiting Farkı

Rate limiting kabul edilen trafik miktarını sınırlar. Backpressure ise downstream kapasitesine göre producer hızını ayarlamaya çalışır.

Distributed Transaction'lar

Monolitik ACID Transaction

Tek veritabanında birden fazla değişiklik tek transaction içinde yönetilebilir.

Service Boundary Sonrası Transaction

Farklı servislerin farklı veritabanları olduğunda tek ACID transaction yaklaşımı zorlaşır.

Partial Failure

Bir servis başarılı olurken başka servis başarısız olabilir.

Eventual Consistency

Sistem kısa süreli tutarsızlıktan sonra event ve düzeltme işlemleriyle tutarlı duruma gelebilir.

Saga Pattern

Choreography

Servisler event'lere tepki vererek merkezi koordinatör olmadan süreci ilerletir.

Orchestration

Merkezi orchestrator hangi adımın ne zaman çalışacağını yönetir.

Compensation

Başarılı bir adımı geri almak için telafi işlemi uygulanabilir.

Saga Ne Zaman Gerekir?

Bir business transaction birden fazla servis sınırını geçtiğinde ve geri alma ihtiyacı varsa değerlendirilebilir.

Transactional Outbox

Database Write

Business verisi veritabanına yazılır.

Outbox Record

Aynı transaction içinde yayımlanacak event için outbox kaydı oluşturulur.

Message Publisher

Ayrı publisher süreci outbox kayıtlarını broker'a gönderir.

Duplicate Delivery

Publisher retry nedeniyle aynı mesajı yeniden gönderebilir.

Idempotent Consumer

Consumer duplicate event'i güvenli biçimde işleyebilmelidir.

Caching ve Client-Server Communication

Client Cache

Client daha önce aldığı veriyi yerel olarak saklayabilir.

Browser Cache

HTTP cache header'ları ile tarayıcı cache davranışı kontrol edilir.

Reverse Proxy

Ortak yanıtları backend'e gitmeden döndürebilir.

CDN

İçeriği kullanıcıya coğrafi olarak yakın noktalardan sunabilir.

Server Cache

Pahalı sorgu ve hesaplamaların sonucunu kısa süreli saklayabilir.

Cache Invalidation

Değişen verinin eski cache kaydıyla sunulmaması için açık invalidation stratejisi gerekir.

HTTP Cache Semantiği

Cache-Control

Yanıtın nerede ve ne kadar süre cache'lenebileceğini belirler.

ETag

Kaynak versiyonunu temsil ederek değişiklik kontrolüne yardımcı olur.

Conditional Request

Client yalnızca kaynak değiştiyse yeni içeriğin dönmesini isteyebilir.

CDN-Friendly API Design

Uygun cache header'ları ve stabil URL tasarımı CDN verimliliğini artırır.

Connection Pooling

Her Request İçin Connection Açmamak

Yeni bağlantı kurulum maliyeti yüksek olabilir. Bağlantıları yeniden kullanmak daha verimlidir.

HTTP Keep-Alive

Aynı TCP bağlantısının birden fazla request için kullanılmasını sağlar.

HTTP/2 Multiplexing

Tek bağlantı üzerinden birden fazla eş zamanlı stream taşınabilir.

gRPC Channel Reuse

Her RPC için yeni channel oluşturmak yerine uzun ömürlü channel kullanmak daha verimlidir.

Pool Exhaustion

Bağlantı havuzu dolduğunda request'ler beklemeye başlayabilir ve latency artabilir.

Dağıtık İletişimde Observability

Logs

Hata, request ve önemli business olaylarını anlamak için bağlamlı log gerekir.

Metrics

Latency, error rate ve throughput düzenli izlenmelidir.

Traces

Tek kullanıcı isteğinin servisler arasında izlediği yol görünür hâle getirilebilir.

Network Metrics

Bağlantı hataları, retransmission, packet loss ve connection süreleri değerlidir.

Communication Topology

Hangi servisin hangisini çağırdığı bilinmeden sistemdeki riskli bağımlılıkları görmek zordur.

Distributed Tracing

Trace

Bir işlemin uçtan uca yaşam döngüsünü temsil eder.

Span

Trace içindeki tek operasyonu gösterir.

Parent-Child Relationship

Servis çağrılarının birbirine nasıl bağlı olduğunu gösterir.

Trace Context

Trace kimliği request header veya message metadata üzerinden taşınabilir.

Service Boundary Propagation

Trace context her servis sınırında doğru şekilde aktarılmalıdır.

Asenkron İletişimde Correlation

Message ID

Tek mesajı benzersiz olarak tanımlar.

Correlation ID

Aynı business akışındaki farklı mesajları ilişkilendirir.

Causation ID

Bir mesajın hangi önceki mesaj nedeniyle oluştuğunu gösterir.

Event Chain

Bu kimlikler sayesinde uzun asenkron işlem zincirleri takip edilebilir.

Her Protokolde Hangi Metrikler İzlenmeli?

REST

Request Rate

Saniye başına request miktarı izlenmelidir.

Error Rate

Başarısız yanıtların oranı takip edilmelidir.

Latency

P50, P95 ve P99 gibi percentile değerleri değerlendirilmelidir.

gRPC

Method Latency

Her RPC metodunun gecikmesi ayrı izlenmelidir.

Stream Duration

Uzun ömürlü stream'lerin süresi ve kapanma nedenleri takip edilmelidir.

Messaging

Queue Depth

Kuyrukta bekleyen mesaj sayısı kapasite sorunlarını gösterebilir.

Oldest Message Age

En eski mesajın ne kadar süredir beklediği operasyonel sağlık açısından güçlü bir göstergedir.

Kafka

Consumer Lag

Consumer'ın producer akışının ne kadar gerisinde kaldığı izlenmelidir.

WebSocket

Active Connections

Aktif bağlantı sayısı kaynak planlamasında önemlidir.

Reconnection Rate

Yüksek reconnect oranı ağ veya server kararsızlığının işareti olabilir.

Dağıtık İletişimde Performance Test

Payload Size

Gerçek üretim payload boyutlarıyla test yapılmalıdır.

Requests per Second

Sistemin sürdürülebilir throughput kapasitesi ölçülmelidir.

P50

Tipik kullanıcı deneyimini gösterir.

P95

Yavaş isteklerin önemli bölümünü görünür hâle getirir.

P99

Tail latency sorunlarını ortaya çıkarır.

Connection Count

Özellikle WebSocket ve yüksek eş zamanlılıkta önemli bir metriktir.

Packet Loss

Gerçek ağ koşullarındaki davranışı görmek için kontrollü kayıp senaryoları test edilebilir.

CPU / Memory

İletişim performansı ölçülürken sunucu kaynak tüketimi de izlenmelidir.

Protokol Benchmark'ları Neden Yanıltıcı Olabilir?

Dil ve Runtime

Farklı programlama dilleri aynı protokolde farklı performans gösterebilir.

Payload

10 byte ile 500 KB payload aynı sonucu vermez.

Serialization

JSON ve binary formatların CPU ve ağ maliyetleri farklıdır.

TLS

Şifreleme ve handshake maliyeti benchmark'a dahil edilmelidir.

Network Distance

Aynı veri merkezindeki sonuç ile kıtalar arası iletişim sonucu aynı değildir.

Connection Reuse

Her request'te yeni bağlantı açılan test gerçek sistemi temsil etmeyebilir.

Gerçek Workload ile Test Etmek

Karar verirken sentetik skor yerine gerçek payload, concurrency ve dependency davranışlarını kullanmak daha sağlıklıdır.

Browser → Server İçin Protokol Seçimi

CRUD → REST/HTTP

Standart veri okuma ve yazma işlemlerinde iyi bir varsayılandır.

Flexible Aggregation → GraphQL

Client'ın farklı ekranlarda farklı veri şekillerine ihtiyaç duyduğu durumlarda değerlendirilebilir.

One-Way Live Updates → SSE

Sunucudan tarayıcıya canlı veri göndermek için basit bir çözümdür.

Interactive Realtime → WebSocket

Çift yönlü ve sürekli iletişim gerektiğinde uygundur.

Advanced Low-Latency Streams → WebTransport'u Değerlendir

Çoklu stream ve datagram ihtiyacı varsa tarayıcı desteğiyle birlikte değerlendirilmelidir.

Mobile → Server İçin Protokol Seçimi

REST

Geniş destek ve kolay debug avantajı sunar.

gRPC

Typed contract ve kompakt payload gereken native uygulamalarda tercih edilebilir.

Network Switching

Wi-Fi ve mobil ağ arasında geçişlerde bağlantının nasıl davrandığı test edilmelidir.

Payload Size

Daha küçük payload mobil veri tüketimini azaltabilir.

Battery

Sık polling ve gereksiz bağlantı kurulumu pil tüketimini artırabilir.

Offline Behavior

Mobil uygulama bağlantısız durumda işlemleri queue'layacak mı sorusu baştan yanıtlanmalıdır.

Service → Service İçin Protokol Seçimi

Simple Request-Response → REST

Basit, düşük hacimli ve debug kolaylığı önemli internal çağrılarda yeterli olabilir.

Typed High-Volume RPC → gRPC

Yüksek throughput ve sıkı contract isteyen servislerde güçlü bir seçenektir.

Background Command → Queue

Sonucun hemen gerekmediği işlerde producer ile worker birbirinden ayrılabilir.

Domain Event → Event Stream

Bir olayın birden fazla sistem tarafından bağımsız tüketilmesi gerektiğinde uygundur.

Birden Fazla Yöntemi Birlikte Kullanmak

Gerçek kurumsal sistemlerde tek protokole bağlı kalmak yerine her iletişim türüne uygun araç seçmek daha doğrudur.

IoT İçin Protokol Seçimi

MQTT

Düşük kaynaklı cihazlar ve pub/sub iletişimi için güçlü bir adaydır.

WebSocket

Çift yönlü sürekli bağlantı gereken daha güçlü cihazlarda kullanılabilir.

HTTP

Seyrek telemetry veya yönetim endpoint'leri için basit olabilir.

Constrained Network

Düşük bant genişliği ve yüksek packet loss ortamlarında protokol ek yükü önem kazanır.

QoS Requirement

Mesajın kaybolup kaybolamayacağına göre uygun teslim seviyesi seçilmelidir.

Partner ve Third-Party Integration İçin Protokol Seçimi

REST

Partner'ın talep üzerine veri çekmesi gereken durumlarda yaygın bir tercihtir.

Webhook

Olay gerçekleştiğinde partner'ı bilgilendirmek için uygundur.

Async File Transfer

Büyük toplu veriler için dosya tabanlı asenkron aktarım daha verimli olabilir.

Public Contract Stability

Partner entegrasyonlarında geriye uyumluluk ve versiyonlama uzun süre korunmalıdır.

Retry ve Idempotency

İnternet üzerinden yapılan entegrasyonlarda duplicate ve geçici hata senaryoları normal kabul edilmelidir.

Real-Time Uygulamalar İçin Protokol Karar Ağacı

Sadece Server Push mu? → SSE

Client yalnızca güncelleme dinliyorsa SSE ile başlayın.

İki Yönlü Mesajlaşma mı? → WebSocket

Client ve server sürekli mesaj gönderecekse WebSocket daha uygundur.

Multiple Streams / Datagram mı? → WebTransport

Daha gelişmiş düşük gecikme ihtiyaçlarında WebTransport değerlendirilebilir.

Device Pub/Sub mı? → MQTT

IoT cihazlarında hafif pub/sub gerekiyorsa MQTT öne çıkar.

Backend Streaming mi? → gRPC / Event Stream

İşlem request bağlamında akıyorsa gRPC, kalıcı event geçmişi gerekiyorsa event streaming düşünülebilir.

Dağıtık Sistemler İçin Hibrit Communication Architecture

Client → API Gateway → REST

Dış istemciler için anlaşılır ve geniş uyumlu API yüzeyi sunar.

Gateway/BFF → Internal Services → gRPC

Internal servisler arasında typed ve yüksek performanslı RPC sağlar.

Business Events → Kafka

Domain event'lerinin birden fazla consumer tarafından işlenmesine ve geçmişin saklanmasına yardımcı olur.

Background Tasks → Queue

Arka plan işleri consumer worker'lara dağıtılır.

Browser Updates → SSE/WebSocket

Tek yönlü güncellemede SSE, çift yönlü iletişimde WebSocket kullanılabilir.

Partner Notifications → Webhooks

Dış sistemlere olay bazlı bildirim göndermek için uygundur.

Protokol Standardizasyonu

Organization-Supported Protocols

Kuruluşun resmi olarak desteklediği sınırlı protokol seti belirlenmelidir.

Default Protocol

Yeni servislerin özel neden yoksa kullanacağı varsayılan iletişim yöntemi tanımlanmalıdır.

Exception Criteria

Varsayılandan ayrılmak için açık teknik gerekçeler aranmalıdır.

Protocol Sprawl Önleme

Her ekibin farklı teknoloji seçmesi bakım ve monitoring maliyetini yükseltir.

Platform Tooling

Logging, tracing, authentication, code generation ve deployment araçları desteklenen protokoller etrafında standartlaştırılabilir.

Protokol Seçiminde Kurumsal Kriterler

Dağıtık sistemlerde iletişim protokolü seçimi performans güvenlik ve ölçeklenebilirlik kriterleri birlikte ele alınarak yapılmalıdır. En hızlı protokol, ekip onu güvenli ve izlenebilir biçimde işletemiyorsa doğru tercih olmayabilir.

Latency

Kabul edilebilir uçtan uca gecikme belirlenmelidir.

Throughput

Saniyede kaç mesaj veya request işleneceği ölçülmelidir.

Reliability

Mesaj kaybının kabul edilip edilemeyeceği netleştirilmelidir.

Ordering

Global veya key bazlı sıra gereksinimi belirlenmelidir.

Bidirectionality

İletişimin tek yönlü mü çift yönlü mü olduğu kararı etkiler.

Browser Compatibility

Doğrudan tarayıcı desteği gerekiyorsa seçenekler daralabilir.

Offline Tolerance

Consumer çevrim dışıyken mesajların beklemesi gerekiyorsa broker tabanlı yaklaşım avantajlıdır.

Security

Encryption, kimlik doğrulama ve authorization desteği değerlendirilmelidir.

Observability

İletişimin log, metric ve trace ile ne kadar görünür olduğu önemlidir.

Operational Complexity

Teknolojinin işletim yükü ekip kapasitesiyle uyumlu olmalıdır.

İletişim Protokolü Karar Matrisi

Public CRUD API → REST

Geniş istemci uyumluluğu ve anlaşılır API deneyimi sunar.

High-Performance Internal RPC → gRPC

Typed contract ve yüksek throughput isteyen servislerde uygundur.

One-Way Browser Stream → SSE

Server push için sade bir seçenek sağlar.

Full-Duplex Browser Communication → WebSocket

Çift yönlü gerçek zamanlı iletişime uygundur.

Advanced HTTP/3 Realtime → WebTransport

Çoklu stream ve datagram gereken modern senaryolarda değerlendirilebilir.

Background Work → Message Queue

Uzun süren işleri kullanıcı request'inden ayırır.

Multi-Consumer Domain Events → Event Streaming

Bir event'i farklı consumer gruplarına dağıtmak ve replay etmek için uygundur.

IoT → MQTT

Düşük kaynaklı cihazlarda hafif pub/sub sağlar.

Enterprise Broker Routing → AMQP

Gelişmiş mesaj routing kurallarında kullanılabilir.

Third-Party Events → Webhook

Dış sisteme event gerçekleştiğinde HTTP callback göndermek için uygundur.

İletişim Protokolü Seçerken Sorulması Gereken 15 Soru

Caller Yanıta Hemen İhtiyaç Duyuyor mu?

Evet ise request-response modeli daha doğal olabilir.

İletişim Tek Yönlü mü?

Tek yönlü ise SSE veya event tabanlı seçenekler değerlendirilebilir.

İletişim Çift Yönlü mü?

Sürekli çift yönlü akışta WebSocket veya uygun streaming protokolü gerekir.

Mesaj Kaybolabilir mi?

Kaybolamıyorsa güvenilir teslim ve retry stratejisi gerekir.

Ordering Gerekli mi?

Gerekliyse hangi kapsamda sıra istendiği tanımlanmalıdır.

Replay Gerekli mi?

Geçmiş olaylar tekrar işlenecekse event stream avantaj sağlar.

Consumer Offline Olabilir mi?

Olabilirse mesajların dayanıklı biçimde saklanması gerekir.

Browser Desteği Gerekiyor mu?

Tarayıcı uyumluluğu protokol seçimini doğrudan sınırlar.

Payload Ne Kadar Büyük?

Büyük payload serileştirme ve bant genişliği maliyetini artırır.

Latency Budget Nedir?

Kabul edilebilir maksimum gecikme net olmalıdır.

Kaç Concurrent Connection Var?

On binlerce persistent connection ile yüzlerce kısa request aynı kapasite modeline sahip değildir.

Contract Ne Kadar Sık Değişiyor?

Sık değişen API'lerde compatibility politikası kritik olur.

Debugging Ne Kadar Önemli?

Üretim sorunlarını hızlı incelemek gerekiyorsa tooling ve okunabilirlik hesaba katılmalıdır.

Ekip Hangi Protokolleri İşletebiliyor?

Teorik avantajlar, ekip bilgisi ve operasyon kabiliyetiyle birlikte değerlendirilmelidir.

Operasyonel Maliyet Ne Kadar?

Yeni protokol yeni monitoring, güvenlik, deployment ve eğitim maliyeti yaratabilir.

Sık Yapılan İletişim Mimarisi Hataları

Her Şeyi REST ile Çözmek

REST güçlüdür ancak queue, stream veya gerçek zamanlı bağlantı ihtiyacını her zaman iyi karşılamaz.

Her Şeyi Kafka ile Çözmek

Her background job veya basit request için event stream kullanmak gereksiz operasyon yükü yaratabilir.

Her Real-Time Problemde WebSocket Kullanmak

Tek yönlü server push gereken bir ekranda SSE daha basit olabilir.

REST'i Protokol Sanmak

REST mimari stildir, çoğunlukla HTTP üzerinde uygulanır.

Async I/O ile Async Messaging'i Karıştırmak

Non-blocking kod yazmak, servisleri zaman açısından birbirinden ayırmaz.

Timeout Kullanmamak

Sınırsız bekleyen bağlantılar kaynak tüketir ve cascading failure riskini artırır.

Bütün Hataları Retry Etmek

Kalıcı hatalar tekrar edilmemeli, geçici hatalar ise kontrollü biçimde denenmelidir.

Idempotency'yi Unutmak

Retry yapılan sistemlerde duplicate işlem riski kaçınılmazdır.

Event ve Command'ı Karıştırmak

Bir olay bildirimi ile belirli bir servisten eylem istemek aynı şey değildir.

Observability'yi Sonradan Eklemek

Dağıtık sistemde sorun ortaya çıktıktan sonra izleme eklemek teşhisi zorlaştırır.

Protokol Sayısını Kontrolsüz Artırmak

Her yeni teknoloji ekip, platform ve operasyon maliyetini artırır.

Kurumsal Communication Definition of Done

Communication Pattern Tanımlı mı?

Senkron, asenkron, queue, pub/sub veya stream modeli açıkça belirtilmelidir.

Protocol Seçimi Gerekçelendirilmiş mi?

Neden REST, gRPC veya başka yöntem seçildiği belgelenmelidir.

Contract Versionlanıyor mu?

API ve event şemalarının değişim politikası olmalıdır.

Timeout Tanımlı mı?

Her remote call için makul timeout sınırı belirlenmelidir.

Retry Policy Tanımlı mı?

Hangi hata için kaç kez retry yapılacağı açık olmalıdır.

Idempotency Gerekiyorsa Var mı?

Duplicate request ve mesajların side effect üretmesi engellenmelidir.

Authentication ve Encryption Var mı?

İletişim taraflarının kimliği doğrulanmalı ve hassas veri şifrelenmelidir.

Observability Var mı?

Metric, log ve trace üretimi tasarımın parçası olmalıdır.

Backpressure/Fan-Out Test Edildi mi?

Yavaş consumer ve yüksek subscriber sayısı altında sistem davranışı test edilmelidir.

Failure Senaryoları Test Edildi mi?

Timeout, servis kesintisi, duplicate mesaj ve network partition gibi durumlar test edilmelidir.

Sık Sorulan Sorular

Client-server mimarisi nedir?

İstemcinin hizmet talep ettiği, sunucunun bu talebi işleyip yanıt ürettiği iletişim modelidir.

Dağıtık sistemlerde servisler nasıl haberleşir?

REST, gRPC, mesaj kuyrukları, event streaming, WebSocket ve başka protokoller üzerinden senkron veya asenkron haberleşebilirler.

REST bir iletişim protokolü müdür?

Hayır. REST bir mimari stildir. Çoğunlukla HTTP protokolü üzerinde uygulanır.

REST mi gRPC mi kullanılmalı?

Public ve browser odaklı API'lerde REST, typed ve yüksek hacimli internal RPC'de gRPC daha uygun olabilir.

HTTP/2 ile HTTP/3 arasındaki fark nedir?

HTTP/2 TCP kullanır. HTTP/3 ise QUIC üzerinde çalışır ve stream seviyesinde kayıpları daha iyi izole edebilir.

TCP ile UDP arasındaki fark nedir?

TCP bağlantılı, güvenilir ve sıralı veri aktarımı sunar. UDP connectionless çalışır ve teslim garantisi vermez.

QUIC nedir?

UDP üzerinde çalışan, şifreleme, güvenilir stream ve bağlantı migration özelliklerini bir araya getiren modern transport protokolüdür.

Senkron ve asenkron iletişim arasındaki fark nedir?

Senkron modelde caller yanıtı bekler. Asenkron modelde mesaj bırakılıp işleme daha sonra devam edebilir.

Message queue ile Kafka arasındaki fark nedir?

Queue çoğunlukla task dağıtımına odaklanır. Kafka benzeri event streaming yaklaşımı event geçmişi, retention ve replay ihtiyaçlarını da karşılar.

WebSocket mı SSE mi?

Tek yönlü server push için SSE, sürekli çift yönlü mesajlaşma için WebSocket daha uygundur.

WebTransport nedir?

HTTP/3 ve QUIC üzerinde tarayıcı ile server arasında çoklu stream ve datagram iletişimi sağlayabilen teknolojidir.

WebTransport WebSocket'ın yerini alacak mı?

Her kullanımda değil. WebSocket geniş uyumluluk ve sade çift yönlü mesajlaşma için güçlü olmaya devam eder.

gRPC browser'da kullanılabilir mi?

Doğrudan native gRPC desteği tarayıcı kısıtları nedeniyle farklıdır. gRPC-Web veya gateway tabanlı çözümler kullanılabilir.

MQTT ne zaman kullanılmalı?

Düşük bant genişliği, hafif pub/sub ve IoT cihaz iletişimi gerektiğinde değerlendirilebilir.

Webhook ile message queue arasındaki fark nedir?

Webhook internet üzerinden HTTP callback gönderir. Message queue ise producer ile consumer arasında broker tabanlı dayanıklı mesajlaşma sağlar.

At-least-once delivery nedir?

Mesajın en az bir kez teslim edilmesini hedefleyen ancak duplicate teslim olasılığını kabul eden modeldir.

Idempotency neden önemlidir?

Retry veya duplicate mesaj nedeniyle aynı business işleminin birden fazla kez uygulanmasını önlemeye yardımcı olur.

Circuit breaker nedir?

Sürekli hata veren dependency'ye yapılan çağrıları geçici olarak durdurarak sistem kaynaklarını koruyan dayanıklılık desenidir.

Service discovery nedir?

Servislerin dinamik olarak hangi adreslerde çalıştığını bulma mekanizmasıdır.

API Gateway ile Service Mesh arasındaki fark nedir?

API Gateway çoğunlukla dış client trafiğini yönetir. Service Mesh ise internal servisler arası east-west trafiğine odaklanır.

Sonuç

Dağıtık Sistemlerde İstemci-Sunucu Mimarisi ve İletişim Protokolleri için en doğru yaklaşım, her iletişim ihtiyacını aynı teknolojiyle çözmeye çalışmamaktır. Kullanıcı isteğinin anlık yanıt gerektirip gerektirmediği, veri hacmi, latency hedefi, güvenlik, retry davranışı, ordering, browser desteği ve operasyon maliyeti birlikte ele alınmalıdır.

Benzer mimari çalışmalarda önce iletişim akışlarını çıkarıp ardından her akış için failure mode, timeout, retry, idempotency ve observability gereksinimlerini belirlemek oldukça işe yarıyor. Protokolü bundan sonra seçmek, teknoloji odaklı değil problem odaklı karar vermeyi sağlar.

Kurumsal dağıtık sistem mimarisi ve iletişim protokolleri danışmanlığı ya da daha geniş kapsamlı sistem tasarımı hakkında bilgi almak için Diyarbakır Yazılım Topluluğu içeriklerini inceleyebilirsiniz. Konuyla ilgili ana kaynağa https://www.diyarbakiryazilim.com.tr/posts/dagitik-sistemlerde-istemci-sunucu-mimarisi-ve-iletisim-protokolleri adresinden ulaşabilirsiniz. Gerçekleştirilen çalışmaları görmek için https://www.diyarbakiryazilim.com.tr/projects sayfasını, topluluk ve çalışma yaklaşımı hakkında bilgi almak için https://www.diyarbakiryazilim.com.tr/about sayfasını ziyaret edebilirsiniz.

Dağıtık sistem ve backend mimarisi danışmanlığı yakınımda şeklinde arama yapıyor ve projeniz için teknik yol haritası oluşturmak istiyorsanız Diyarbakır Yazılım Topluluğu ile https://www.diyarbakiryazilim.com.tr üzerinden iletişime geçebilirsiniz.

Dağıtık Sistemlerde İstemci-Sunucu Mimarisi Hakkında Ek Sorular

Dağıtık sistemlerde istemci-sunucu mimarisi nasıl çalışır ve hangi avantajları sağlar?

İstemci bir isteği uygun sunucuya veya gateway katmanına gönderir. Sunucu isteği işler, gerekiyorsa başka servislerle haberleşir ve sonucu döndürür. Bu model görevleri ayırmayı, servisleri bağımsız ölçeklemeyi ve güvenlik politikalarını merkezi noktalarda uygulamayı kolaylaştırabilir.

Dağıtık sistemlerde REST, gRPC, WebSocket ve mesaj kuyrukları arasından hangi iletişim protokolü seçilmelidir?

Tek bir doğru yoktur. Public CRUD API için REST, typed internal RPC için gRPC, çift yönlü gerçek zamanlı iletişim için WebSocket ve sonucun hemen gerekmemesi durumunda mesaj kuyrukları tercih edilebilir. İyi mimariler çoğu zaman bu yöntemleri birlikte kullanır.

İstemci ve sunucu arasındaki senkron ve asenkron iletişimin farkları nelerdir?

Senkron iletişimde istemci yanıtı bekler ve iki taraf aynı anda erişilebilir olmalıdır. Asenkron iletişimde iş broker veya queue üzerinden daha sonra işlenebilir. Bu sayede servisler zaman açısından daha bağımsız çalışabilir.

Dağıtık sistemlerde ağ gecikmesi, bağlantı hataları ve veri tutarlılığı nasıl yönetilir?

Timeout, retry budget, exponential backoff, jitter, circuit breaker, idempotency, event tabanlı telafi süreçleri ve güçlü observability birlikte kullanılır. Veri tutarlılığı için her işlemin kesin olarak anında tutarlı olması yerine bazı alanlarda eventual consistency tercih edilebilir.

Yakınımda dağıtık sistem mimarisi ve iletişim protokolleri konusunda danışmanlık veren yazılım firması nasıl bulabilirim?

Teknik danışmanlık ararken yalnızca kullanılan teknolojilere değil, ekibin failure senaryoları, performans testi, güvenlik, observability ve ölçeklenebilirlik konularındaki yaklaşımına bakmak faydalıdır. Diyarbakır Yazılım Topluluğu hakkında ayrıntılı bilgiye https://www.diyarbakiryazilim.com.tr üzerinden ulaşabilirsiniz.