# Apache Kafka ile Veri Muhendisligi: Partition Stratejileri, Consumer Groups ve Streaming Mimarisi

> Veri muhendisleri icin kapsamli Apache Kafka rehberi. Streaming mimarisi, partition stratejileri, consumer groups, KRaft modu, Debezium ile CDC, exactly-once semantigi ve mulakat sorulari. Python kod ornekleri ile aciklamali.

- Published: 2026-04-20
- Updated: 2026-04-20
- Author: SharpSkill
- Tags: kafka, streaming, data-engineering, partitions, consumer-groups, kraft, event-driven
- Reading time: 12 min

---

Apache Kafka, modern veri muhendisligi mimarilerinin merkezinde yer alan dagitik bir streaming platformudur. LinkedIn bunyesinde kullanici aktivite akislarini islemek amaciyla gelistirilen Kafka, gunumuzde Netflix, Uber, Airbnb ve diger buyuk olcekli platformlarin veri altyapisinin temel tasini olusturmaktadir. 2026 yilinda gunluk trilyonlarca olayin islendigi Kafka ekosistemi, veri muhendisleri icin vazgecilmez bir arac haline gelmistir. Partition mekanizmalari, consumer group yapisi, teslimat garantileri ve KRaft modu gibi temel kavramlara hakimiyet, guvenilir ve olceklenebilir veri pipeline'lari tasarlamanin on kosulunu olusturmaktadir.

> **Kafka 4.x: ZooKeeper Donemi Sona Erdi**
>
> Kafka 4.0 surumunden itibaren ZooKeeper tamamen kaldirilmistir. KRaft (Kafka Raft) modu, cluster metadata yonetimini dogrudan Kafka bunyesinde gerceklestirerek dagitim ve bakim sureclerini onemli olcude basitlestirmektedir. Yeni olusturulan tum Kafka cluster'lari KRaft modunda yapilandirilmalidir.

## Kafka 4.x KRaft Cluster Kurulumu

Kafka ile calismanin ilk adimi, yerel bir gelistirme cluster'inin kurulmasidir. Surum 4.0 ile birlikte ZooKeeper bagimliligi ortadan kalkmistir. KRaft modu, konsensus mekanizmasini dogrudan Kafka broker'larina entegre ederek yonetilmesi gereken bilesenleri azaltmakta ve uretim ortamlarinda sik karsilasilan bir hata kaynagini ortadan kaldirmaktadir.

Asagidaki Docker Compose yapilandirmasi, uc dugumlu bir Kafka 4.2 cluster'ini KRaft modunda olusturmaktadir. Her dugum hem broker hem de controller rolunu ustlenmektedir; bu yapilandirma gelistirme ve test ortamlari icin idealdir:

```yaml
# docker-compose.yml — Kafka 4.x KRaft cluster (no ZooKeeper)
services:
  kafka-1:
    image: apache/kafka:4.2.0
    environment:
      KAFKA_NODE_ID: 1
      KAFKA_PROCESS_ROLES: broker,controller
      KAFKA_CONTROLLER_QUORUM_VOTERS: 1@kafka-1:9093,2@kafka-2:9093,3@kafka-3:9093
      KAFKA_LISTENERS: PLAINTEXT://:9092,CONTROLLER://:9093
      KAFKA_INTER_BROKER_LISTENER_NAME: PLAINTEXT
      KAFKA_CONTROLLER_LISTENER_NAMES: CONTROLLER
      KAFKA_LOG_DIRS: /var/lib/kafka/data
      KAFKA_NUM_PARTITIONS: 6
      KAFKA_DEFAULT_REPLICATION_FACTOR: 3
      KAFKA_MIN_INSYNC_REPLICAS: 2
    ports:
      - "9092:9092"
```

`KAFKA_CONTROLLER_QUORUM_VOTERS` degiskeni, Raft quorum'una katilacak dugumleri tanimlar. Replikasyon faktoru 3 ve minimum senkron replika sayisi 2 (`MIN_INSYNC_REPLICAS`) olarak ayarlandiginda, cluster bir dugumun kaybini hizmet kesintisi veya veri kaybi olmadan tolere edebilmektedir. Bu yapilandirma, uretim ortamina yakin senaryolar icin onerilen minimum standardi temsil etmektedir.

## Streaming Mimarisi ve Partition Stratejileri

Partition'lar, Kafka'nin paralellik mekanizmasinin temelini olusturur. Her topic bir veya daha fazla partition'a bolunur ve her partition, sirali ve degistirilemez bir log yapisina sahiptir. Ayni partition icindeki mesajlar katı bir sekilde siralanirken, farkli partition'lar arasinda herhangi bir siralama garantisi bulunmamaktadir.

Partition anahtarinin (partition key) secimi, hangi mesajlarin hangi partition'a yonlendirilecegini belirler. Bu secim, uc kritik boyutu dogrudan etkiler: isleme sirasi, yuk dagitimi ve olceklendirme kapasitesi.

```python
# partition_strategy.py — Choosing the right partition key
from confluent_kafka import Producer
import json

def create_producer():
    return Producer({
        'bootstrap.servers': 'kafka-1:9092',
        'acks': 'all',
        'enable.idempotence': True,
        'max.in.flight.requests.per.connection': 5
    })

def publish_order_event(producer, event):
    # Key by customer_id: all events for one customer stay ordered
    key = str(event['customer_id']).encode('utf-8')
    value = json.dumps(event).encode('utf-8')
    producer.produce(
        topic='order-events',
        key=key,
        value=value,
        headers=[('source', b'order-service'), ('version', b'2')]
    )
    producer.flush()

def publish_clickstream(producer, event):
    # Key by session_id: ordering within a session matters
    # NOT by user_id — one user may have multiple sessions
    key = str(event['session_id']).encode('utf-8')
    value = json.dumps(event).encode('utf-8')
    producer.produce(
        topic='clickstream',
        key=key,
        value=value
    )
```

Yukaridaki ornekte siparis olaylari `customer_id` ile partitionlanmaktadir. Ayni musteriye ait tum olaylar ayni partition'a yonlendirilerek kronolojik sirada islenmesi garanti altina alinmaktadir. Clickstream verileri icin ise `session_id` (kullanici kimliginden farkli olarak) partition anahtari olarak secilmistir. Bu yaklasim, bir oturum icindeki eylemlerin sirasini korurken, ayni anda birden fazla oturumu olan kullanicilarda yukunun daha fazla partition'a dagitilmasini saglamaktadir.

### Partition Sayisinin Belirlenmesi

Bir topic'in partition sayisi, tuketici tarafinda ulasabilecek maksimum paralellik duzeyini belirler. Ornegin, 12 partition'a sahip bir topic'te ayni consumer group icinde en fazla 12 tuketici paralel olarak calisabilir; 13. tuketici bosta kalacaktir.

Pratik bir kural olarak hedef veri hacmi (MB/s) tek bir tuketicinin isleyebilecegi maksimum verime bolunmelidir. Saniyede 120 MB veri alan ve her biri 10 MB/s isleyebilen tuketiciler icin 12 partition makul bir baslangic noktasidir. Mevcut bir topic'in partition sayisini artirmak, anahtarlarin yeniden dagitilmasina ve siralama garantilerinin gecici olarak bozulmasina neden olacagindan, baslangicta biraz fazla partition tanimlamak tercih edilmelidir.

> **Hot Partition Tehlikesi**
>
> Partition anahtari iyi secilmezse -- ornegin, trafik yukunun yuzde 80'ini olusturan tek bir satici kimliginin anahtar olarak kullanilmasi -- bir partition mesajlarin buyuk cogulugunu alir. Hot partition olarak adlandirilan bu dengesizlik, ilgili broker'in asiri yuklenmesine yol acar ve paralellik avantajini ortadan kaldirir. Temel kural: degerler arasinda esit dagilim gosteren bir anahtar secilmelidir.

## Consumer Groups ve Offset Yonetimi

Consumer group'lar, ayni hizmetin birden fazla orneginin bir topic'in islemesini paylasmasina olanak tanir. Kafka, her partition'i gruptaki tek bir tuketiciye otomatik olarak atar ve ayni grup icinde hicbir mesajin birden fazla kez islenmemesini garanti eder.

Offset yonetimi -- her partition'daki okuma konumunun takibi -- Kafka tuketicisinin en hassas bilesenidir. Varsayilan mod (`enable.auto.commit = True`), offset'leri periyodik olarak commit eder ve bu durum, cokme aninda mesajlarin birden fazla kez islenmesine veya kaybolmasina yol acabilir. Veri pipeline'lari icin, basarili islemeden sonra manuel commit yapmak zorunludur.

```python
# consumer_pipeline.py — Consumer group with manual offset management
from confluent_kafka import Consumer, KafkaError
import json

def create_consumer(group_id: str):
    return Consumer({
        'bootstrap.servers': 'kafka-1:9092',
        'group.id': group_id,
        'auto.offset.reset': 'earliest',
        'enable.auto.commit': False,  # Manual commit for at-least-once
        'max.poll.interval.ms': 300000,
        'session.timeout.ms': 45000,
        'isolation.level': 'read_committed'  # Only read committed transactions
    })

def process_batch(consumer: Consumer, batch_size: int = 500):
    """Process records in micro-batches for throughput."""
    consumer.subscribe(['order-events'])
    buffer = []

    while True:
        msg = consumer.poll(timeout=1.0)
        if msg is None:
            continue
        if msg.error():
            if msg.error().code() == KafkaError._PARTITION_EOF:
                continue
            raise Exception(msg.error())

        record = json.loads(msg.value().decode('utf-8'))
        buffer.append(record)

        if len(buffer) >= batch_size:
            # Process the full batch (write to warehouse, etc.)
            write_to_warehouse(buffer)
            # Commit AFTER successful processing
            consumer.commit(asynchronous=False)
            buffer.clear()

def write_to_warehouse(records: list):
    # Insert batch into data warehouse (BigQuery, Snowflake, etc.)
    pass
```

`isolation.level: read_committed` parametresi, tuketicinin iptal edilmis transaksiyonlardan gelen mesajlari okumasini engeller. Senkron manuel commit ile birlestirildiginde bu desen, at-least-once semantigini garanti eder: tuketici yeniden baslatilsa bile her mesaj en az bir kez islenir. Mikro-batch boyutu (bu ornekte 500) gecikme ile verim arasinda bir denge noktasidir; daha buyuk batch'ler throughput'u artirirken isleme gecikmesini de yukseltir.

## Kafka Connect ve Debezium ile Change Data Capture

Change Data Capture (CDC), veri muhendisligi baglaminda Kafka'nin en guclu kullanim alanlarindan birini temsil etmektedir. Kaynak veritabanina periyodik sorgular (polling) gondermek yerine, Debezium PostgreSQL, MySQL veya MongoDB'nin transaksiyonel gunlugunu (WAL) okuyarak her degisikligi bir Kafka topic'ine olay olarak yayinlar.

Bu yaklasim uc onemli avantaj sunar: veritabanindaki degisiklik ile yayilma arasinda neredeyse sifir gecikme, kaynak veritabanina ek yuk bindirilmemesi (WAL okuma pasif bir islemdir) ve silme islemleri dahil tum operasyonlarin eksiksiz yakalanmasi.

```json
{
  "name": "postgres-cdc-source",
  "config": {
    "connector.class": "io.debezium.connector.postgresql.PostgresConnector",
    "database.hostname": "postgres-primary",
    "database.port": "5432",
    "database.user": "replication_user",
    "database.dbname": "production",
    "topic.prefix": "cdc",
    "table.include.list": "public.orders,public.customers,public.products",
    "slot.name": "debezium_slot",
    "plugin.name": "pgoutput",
    "publication.name": "dbz_publication",
    "snapshot.mode": "initial",
    "transforms": "route",
    "transforms.route.type": "org.apache.kafka.connect.transforms.RegexRouter",
    "transforms.route.regex": "cdc\\.public\\.(.*)",
    "transforms.route.replacement": "warehouse.$1"
  }
}
```

Bu Debezium yapilandirmasi, uretim ortamindaki bir PostgreSQL veritabanindan `orders`, `customers` ve `products` tablolarindaki degisiklikleri yakalamaktadir. `snapshot.mode: initial` ayari, streaming moduna gecmeden once tablolarin mevcut durumunun eksiksiz bir anlk goruntusunu alir. `RegexRouter` donusumu cikis topic'lerini yeniden adlandirir (ornegin `cdc.public.orders`, `warehouse.orders` olur) ve veri ambarına yonlendirmeyi basitlestirmektedir.

> **CDC ve Periyodik Sorgulama Karsilastirmasi**
>
> Debezium ile CDC, degisiklikleri 100 milisaniyenin altinda tespit ederken, klasik SQL polling islemi dakikalar hatta saatler alabilir. Bu fark, operasyonel panolari veya dolandiricilik tespit sistemlerini besleyen pipeline'lar icin belirleyicidir. Ayrica CDC, silme islemlerini (DELETE) yakalar; timestamp tabanli polling ise soft delete gibi ek mekanizmalar olmadan bunu gerceklestirememektedir.

## Exactly-Once Semantigi: Uctan Uca Transaksiyonel Pipeline

Exactly-once semantigi, streaming pipeline'larinin en yuksek guvenilirlik seviyesini temsil eder. Bu garanti olmadan bir pipeline ya tekrar eden kayitlar uretir (at-least-once) ya da mesaj kaybi yasanir (at-most-once). Kafka, exactly-once semantigini uretici transaksiyonlari ile tuketici tarafindaki `read_committed` izolasyonunun birlesimi araciligiyla uygulamaktadir.

Consume-transform-produce deseni bu mekanizmayi somutlastirir: tuketici bir mesaj okur, donusturur, sonucu bir cikis topic'ine yazar ve kaynak mesajin offset'ini commit eder -- tumu tek bir atomik transaksiyonda gerceklesir.

```python
# exactly_once_pipeline.py — Transactional consume-transform-produce
from confluent_kafka import Consumer, Producer
import json

def transactional_pipeline():
    consumer = Consumer({
        'bootstrap.servers': 'kafka-1:9092',
        'group.id': 'etl-transformer',
        'enable.auto.commit': False,
        'isolation.level': 'read_committed'
    })

    producer = Producer({
        'bootstrap.servers': 'kafka-1:9092',
        'transactional.id': 'etl-transformer-001',
        'acks': 'all',
        'enable.idempotence': True
    })

    producer.init_transactions()
    consumer.subscribe(['raw-events'])

    while True:
        msg = consumer.poll(1.0)
        if msg is None or msg.error():
            continue

        # Begin atomic transaction
        producer.begin_transaction()
        try:
            raw = json.loads(msg.value())
            enriched = transform(raw)

            # Write transformed record to output topic
            producer.produce(
                'enriched-events',
                key=msg.key(),
                value=json.dumps(enriched).encode('utf-8')
            )

            # Commit consumer offset within the same transaction
            producer.send_offsets_to_transaction(
                consumer.position(consumer.assignment()),
                consumer.consumer_group_metadata()
            )
            producer.commit_transaction()
        except Exception:
            producer.abort_transaction()

def transform(record: dict) -> dict:
    # Apply business logic transformations
    record['processed_at'] = '2026-04-20T00:00:00Z'
    record['pipeline_version'] = '2.1'
    return record
```

`transactional.id`, bu pipeline ornegini benzersiz olarak tanimlar. Yeniden baslatma durumunda Kafka, bu tanimlayiciyi kullanarak onceki ornegin tamamlanmamis transaksiyonlarini iptal eder ve boylece tekrarlanan kayitlari onler. `send_offsets_to_transaction` cagrisi, tuketici offset commit'ini zenginlestirilmis mesajin uretilmesiyle ayni transaksiyona baglar: ya her iki islem birlikte commit edilir ya da hicbiri edilmez.

> **Transaksiyonlarin Performans Maliyeti**
>
> Kafka transaksiyonlari goz ardi edilemeyecek bir ek yuk getirir. Her transaksiyonda dahili koordinasyon topic'lerine ek yazmalar gerceklestirilir. Saniyede 100.000'den fazla mesaj islenen yuksek hacimli pipeline'larda, her mesaj icin ayri bir transaksiyona baslamak yerine birden fazla mesajin tek bir transaksiyonda gruplanmasi tercih edilmelidir. Transaksiyona basina 100 ila 500 mesajlik bir batch, garanti ve performans arasinda optimal dengeyi saglamaktadir.

## Share Groups: Yeni Tuketim Paradigmasi (KIP-932)

Kafka 4.0 ile birlikte sunulan Share Groups, tuketim modelinde kokllu bir degisimi temsil etmektedir. Klasik consumer group'larda her partition yalnizca bir tuketiciye atanirken, Share Groups birden fazla tuketicinin ayni partition'u esanli olarak okumasina olanak tanir ve mesaj bazinda onaylama mekanizmasi sunar.

Bu model, geleneksel mesaj kuyruklari (RabbitMQ, SQS) yaklasimini Kafka'nin avantajlariyla birlestirmektedir. Isleme sirasinin kritik olmadigi ancak tuketiciler arasinda esit yuk dagitiminin onemli oldugu is yuklerinde ozellikle etkili bir cozum sunmaktadir.

| Feature | Consumer Groups | Share Groups |
|---|---|---|
| Partition assignment | Exclusive (one consumer per partition) | Shared (multiple consumers per partition) |
| Ordering guarantee | Per-partition ordering preserved | No ordering guarantee |
| Use case | Ordered event streams | Task distribution, work queues |
| Acknowledgement | Offset-based (commit position) | Per-record (acknowledge individually) |
| Max parallelism | Limited by partition count | Limited by consumer count |

Share Groups, klasik consumer group'larin yerini almamaktadir. Her iki model birlikte var olmakta ve farkli ihtiyaclara yanit vermektedir. Olaylarin sirasinin kritik oldugu bir ETL pipeline'inda klasik consumer group'lar dogru secimdir. Hesaplama gorevlerinin dagitilmasinda ise (rapor olusturma, bildirim gonderme gibi) Share Groups, partition sayisi kisitlamasi olmaksizin ustun bir olceklendirme kapasitesi sunmaktadir.

## Kafka ile Event-Driven Mimariler

Kafka yalnizca sistemler arasinda veri tasimakla sinirli degildir. Event-driven bir mimaride her is durumu degisikligi bir olay olarak yayinlanir. Alt sistemler bu olaylara asenkron olarak tepki vererek bilesenlerin birbirinden ayrismasini ve sistemin genel dayanikliligin artmasini saglar.

Veri muhendisliginde Kafka kullaniminda uc mimari desen on plana cikmaktadir:

**Event Sourcing**: Bir varligin mevcut durumunu saklamak yerine, o duruma ulastiran tum olaylar muhafaza edilir. Kafka topic'i degistirilemez bir gerceklik kaynagi olarak gorev yapar. Mevcut durum, olaylar log'un basindan itibaren tekrar oynatilarak yeniden olusturulur. Bu desen denetim, hata ayiklama ve maddilesmis gorunum yeniden yapilandirmasi icin son derece uygundur.

**CQRS (Command Query Responsibility Segregation)**: Yazma (komut) ve okuma (sorgu) islemleri farkli yollar izler. Kafka dogrulanmis komutlari, okuma icin optimize edilmis maddilesmis gorunumleri guncelleyen tuketicilere tasir. Bu desen, yazma ve okuma operasyonlarinin birbirinden bagimsiz olarak olceklenmesini mumkun kilar.

**Streaming ETL**: Veriler batch penceresi olmaksizin surekli olarak cikarilir, donusturulur ve yuklenir. Debezium degisiklikleri gercek zamanli yakalar, bir stream islemci (Kafka Streams, Flink) donusumleri uygular ve sonuc veri ambarina veya veri golune yazilir. Verinin guncelliginin kritik oldugu kullanim senaryolarinda bu desen, gecelik batch pipeline'larin yerini giderek almaktadir.

## Mulakat Sorulari: Veri Muhendisleri icin Kafka

Veri muhendisligi pozisyonlarina yonelik teknik mulakatlarda Kafka ile ilgili derinlemesine sorularla siklikla karsilasilmaktadir. Asagidaki sorular, 2026 yilinda en cok degerlendirilen kavramlari kapsamaktadir. Daha fazla mulakat sorusu icin [veri muhendisligi teknoloji sayfasi](/tr/technologies/data-engineering), [ETL/ELT desenleri mulakat sorulari](/tr/technologies/data-engineering/interview-questions/etl-elt-patterns) ve [veri modelleme mulakat sorulari](/tr/technologies/data-engineering/interview-questions/data-modeling-de) sayfalari incelenebilir.

**Kafka mesaj sirasini nasil garanti eder?**
Siralama yalnizca partition icinde garanti edilir. Ayni partition anahtarini paylasan tum mesajlar ayni partition'a yonlendirilir ve uretim sirasinda islenir. Partition'lar arasinda hicbir siralama garantisi bulunmaz. Kuresel bir sira icin tek partition'li bir topic gereklidir ancak bu tum paralellik avantajini ortadan kaldirir.

**At-least-once, at-most-once ve exactly-once arasindaki fark nedir?**
At-most-once: tuketici offset'i islemeden once commit eder; basarisizlik durumunda mesaj kaybolur. At-least-once: tuketici islemeden sonra commit eder; basarisizlik ve yeniden baslatma durumunda mesaj tekrar islenir. Exactly-once: uretici transaksiyonlari, idempotence ve `read_committed` izolasyonunun birlesimi, arizalar olsa bile her mesajin tam olarak bir kez islenmesini garanti eder.

**Consumer group'ta rebalancing nasil calisir?**
Bir tuketici gruba katildiginda veya gruptan ayrildiginda Kafka bir rebalancing tetikler. Bu asamada tum partition'lar gecici olarak serbest birakilir ve yeniden atanir. Rebalancing sirasinda isleme duraksama yasanir. Isbirlikci stratejiler (Cooperative Sticky Assignor) yalnizca etkilenen partition'lari yeniden atayarak etkiyi en aza indirir.

**Bir broker cokerse ne olur?**
Broker lider partition'lara ev sahipligi yapiyorsa, Kafka senkron replikalar (ISR) arasinda yeni liderler secer. Uretici ve tuketiciler otomatik olarak yeni liderlere yonlendirilir. Cokme sonrasinda `min.insync.replicas` kosulu artik karsilanamiyorsa, `acks=all` ile gerceklestirilen uretimler yeterli sayida replika yeniden senkronize olana kadar basarisiz olacaktir.

**Kafka Streams ile Flink arasinda nasil secim yapilir?**
Kafka Streams, uygulamaya gomulu bir kutuphanedir. Ayri bir isleme cluster'i gerektirmez ve saniyede yuz binlerce mesaja kadar orta karmasikliktaki donusumler icin uygundur. Flink ise bagimsiz bir dagitik isleme motorudur; karmasik islemler (gelismis pencere yonetimi, karmasik olay isleme, coklu akis birlestirme) ve asiri yuksek hacimler icin tasarlanmistir. Secim, islemenin karmasikligina ve ek bir cluster isletme istegiyle dogrudan iliskilidir.

**Kafka'da sema evrimi nasil yonetilir?**
Schema Registry (Confluent veya Apicurio), Avro, Protobuf veya JSON Schema semalarini saklayip versiyonlar. Ureticiler, uretim oncesinde semayi kaydeder ve tuketiciler tuketim aninda uyumlulugu dogrular. Uyumluluk politikalari (BACKWARD, FORWARD, FULL), mevcut tuketicileri bozabilecek yikici sema degisikliklerini onler.

## Izleme ve Gozlemlenebilirlik

Uretim ortamindaki bir Kafka cluster'i, bircok kritik metrigin aktif olarak izlenmesini gerektirir. Yeterli izleme olmadan kacinilmaz olarak sessiz arizalarla karsilasilir: biriken consumer lag, yetersiz replikasyona sahip partition'lar veya uyari olusturmadan dolan diskler.

Izlenmesi gereken en kritik metrikler sunlardir:

- **Consumer lag**: Uretilen son offset ile tuketici tarafindan commit edilen son offset arasindaki fark. Artan bir lag, tuketicinin uretim hizina yetisemedigi anlamina gelir ve belirlenen esigin uzerinde bir uyari tetiklenmelidir.
- **Under-replicated partitions**: Replikalari lider ile senkronize olmayan partition sayisi. Birkac dakikadan uzun sure sifirdan buyuk bir deger, bir ag sorunu veya zorlanmakta olan bir broker'i isaret eder.
- **Request latency (produce/fetch)**: Uretim ve tuketim isteklerinin yanit suresi. Ani bir artis, genellikle disk veya ag doygunluguna isaret eder.
- **Disk kullanimi**: Kafka mesajlari diskte saklar. Tutma politikasi (sure veya boyut bazli) disk dolmasini onleyecek sekilde kalibre edilmelidir.

LinkedIn tarafindan gelistirilen Burrow, consumer lag izleme icin referans arac olmaya devam etmektedir. Daha kapsamli bir gorunum icin Prometheus ve Grafana ile Kafka'nin JMX metrikleri birlesimi, detayli panolar ve yapilandirilebilir uyarilar saglamaktadir.

## Sonuc

Apache Kafka, veri muhendisliginde streaming altyapisinin referans platformu olarak konumunu surmektedir. Temel cikarimlar su sekilde ozetlenebilir:

- KRaft modu (Kafka 4.x), ZooKeeper'i ortadan kaldirarak cluster dagitim ve yonetimini onemli olcude basitlestirmektedir
- Partition anahtari secimi, isleme sirasi, yuk dagitimi ve olceklendirmeyi dogrudan belirler -- hatali bir anahtar secimi hot partition sorununa ve performans kayiplarina neden olur
- `enable.auto.commit: False` ile manuel offset commit ve `read_committed` izolasyonu, guvenilir bir at-least-once pipeline'inin temelini olusturur
- Debezium ile CDC, kaynak veritabaninin WAL'indan gercek zamanli degisiklikleri performans etkisi olmadan yakalar
- Kafka transaksiyonlari (exactly-once), consume-transform-produce deseninin atomikligini garanti eder; batch boyutlari ile kalibre edilmesi gereken bir performans maliyeti tasir
- Share Groups (KIP-932), Kafka 4.0 ile birlikte siralama kisitlamasi olmayan is kuyrugu senaryolari icin yeni bir tuketim modeli sunmaktadir
- Consumer lag, yetersiz replikasyonlu partition'lar ve istek gecikmesinin izlenmesi, uretim ortamindaki sessiz arizalarin onlenmesi icin zorunludur
- Kafka ile acik tablo formatlari (Iceberg, Delta Lake) arasindaki yakinlasma, modern veri platformlarinin referans mimarisini sekillendirmektedir

---

Source: SharpSkill (https://sharpskill.dev), tech interview preparation for your real stack.
HTML version of this page: https://sharpskill.dev/tr/blog/data-engineering/apache-kafka-data-engineering-streaming-partitions