Kafka, log di jantung sistem Anda.

Buang pemasaran dan Kafka satu hal: log peristiwa terdistribusi, append-only, tahan lama yang dibaca banyak consumer independen dengan kecepatan mereka sendiri. Bukan antrean, bukan database, bukan message bus dalam arti klasik, sebuah log. Producer menambahkan record ke ujung; consumer membaca maju dari posisi yang mereka lacak sendiri; dan record tetap setelah dibaca, selama retensi terkonfigurasi. Begitu satu gambar itu masuk kepala Anda, setiap fitur di manual ini konsekuensinya.

Deskripsi resminya "platform event streaming terdistribusi," dan tiap kata layak tempatnya. Distributed: ia berjalan sebagai klaster broker, mereplikasi data demi toleransi kegagalan dan scaling horizontal. Event streaming: ia dibangun di sekitar aliran event immutable yang tak terbatas dan berkelanjutan (sesuatu terjadi: order ditempatkan, pembayaran jelas, sensor membaca), bukan panggilan request/response. Platform: producer, consumer, ekosistem konektor, dan stream processing semuanya duduk di log yang sama.

Ini bagian terpenting di manual, karena mencampurkan Kafka dengan message queue tradisional akar sebagian besar kebingungan. Bab task-queues mencakup model antrean secara mendalam, producer, worker, broker seperti RabbitMQ dan SQS, retry, visibility timeout. Kafka jenis benda yang berbeda, dan perbedaannya bukan detail; ia mengubah masalah apa yang dipecahkan.

Semua yang Kafka lakukan bertumpu pada struktur data paling rendah hati dalam komputasi: log append-only: urutan record terurut yang hanya bisa Anda tambahkan di ujung, tidak pernah menyisipkan di tengah atau memodifikasi. Tiap record mendapat offset yang naik monoton (0, 1, 2, ...) yang menjadi alamat permanennya. Ini struktur yang sama yang dipakai database untuk write-ahead log dan daya tahannya; wawasan Kafka menjadikan log itu sendiri abstraksi primer yang publik alih-alih detail internal tersembunyi.

Kenapa log append-only begitu cepat dan begitu berguna

• I/O sekuensial murah. Menambahkan ke ujung file dan membacanya maju operasi disk sekuensial, jauh lebih cepat daripada akses acak, bahkan di SSD. Kafka bersandar pada OS page cache dan transfer zero-copy untuk memindahkan data dari disk ke jaringan tanpa melewati memori aplikasi, begitulah ia menopang jutaan pesan per detik di perangkat keras sederhana.
• Immutabilitas sederhana & aman. Record tidak pernah berubah, jadi tidak ada lock untuk update, tidak ada konflik baca/tulis, dan pembaca serentak tidak pernah mengganggu. Riwayat immutable juga sepele di-cache dan mudah dinalar.
• Log adalah riwayatnya. Karena tidak ada yang ditimpa, log catatan lengkap terurut dari semua yang terjadi, persis yang membuat replay (bagian 11), event sourcing (bagian 14), dan memberi makan consumer baru dari awal mungkin.

Topic aliran bernama dari event terkait, orders, payments, page-views. Ia kanal logis yang ditulis producer dan dibaca consumer. Tapi topic bukan satu log; ia dipecah menjadi partisi, dan partisi tempat semua mekanik nyata hidup. Partisi sekaligus unit Kafka untuk paralelisme, urutan, dan penyimpanan, tiga properti terpenting dalam sistem, semuanya menumpang satu konsep ini.

Tiga peran partisi

• Paralelisme. Partisi bisa hidup di broker berbeda dan dikonsumsi consumer berbeda sekaligus, jadi throughput topic berskala dengan jumlah partisinya. Lebih banyak partisi -> lebih banyak konsumsi paralel (sampai batas consumer group, bagian 7).
• Urutan. Kafka menjamin urutan dalam satu partisi dan tidak berjanji apa pun lintas partisi. Ini kompromi sentral (bagian 10): untuk menjaga event terkait terurut, rutekan mereka ke partisi yang sama via key bersama (semua event untuk order-42 memakai key "order-42", jadi mereka terurut ketat relatif satu sama lain).
• Penyimpanan. Setiap partisi secara fisik satu set file segmen di disk broker, log append-only aktual dari bagian 3. Retensi dan kompaksi (bagian 11) beroperasi per partisi.

Klaster Kafka satu set broker (server); partisi tersebar di antara mereka, dan begitulah klaster berskala dan selamat dari kegagalan. Daya tahan datang dari replikasi: tiap partisi punya satu replika leader dan beberapa replika follower di broker lain. Semua baca dan tulis pergi ke leader; follower terus menyalin darinya. Jika broker leader mati, follower dipromosikan, tanpa data hilang, ketidaktersediaan singkat. Ini pola pikir desired-state/failover yang sama dengan bab Kubernetes, diterapkan ke data.

Kenop daya tahan: acks & ISR

Seberapa aman sebuah tulis bergantung dua setelan. acks producer menyebut berapa replika yang harus mengonfirmasi sebelum tulis dianggap selesai: acks=0 (fire-and-forget, bisa kehilangan data), acks=1 (leader saja, hilang jika leader mati sebelum follower menyalin), atau acks=all (leader plus semua in-sync replica: pilihan aman). ISR (in-sync replica set) follower yang saat ini mengejar leader; memasangkan acks=all dengan min.insync.replicas=2 berarti tulis hanya sukses jika setidaknya dua replika memilikinya, selamat dari satu kehilangan broker dengan nol kehilangan data.

Producer menerbitkan record ke topic. Tiga perhatian producer membentuk kebenaran dan performa: key (yang menentukan partisi dan karenanya urutan, bagian 4), acks (daya tahan, bagian 5), dan batching (producer mengelompokkan record dan mengompresnya untuk throughput). Record pasangan key/value plus header opsional dan timestamp; value payload event Anda (sering Avro/Protobuf, bagian 12).

// Using confluent-kafka-go (librdkafka). kafka-go (segmentio) is a pure-Go alternative.
p, _ := kafka.NewProducer(&kafka.ConfigMap{
    "bootstrap.servers": "localhost:9092",
    "acks":              "all",   // durability: leader + in-sync replicas (sec 5)
    "enable.idempotence": true,   // no duplicates on producer retry (sec 9)
    "linger.ms":         5,       // wait up to 5ms to batch records (throughput)
    "compression.type":  "zstd",
})
defer p.Close()

topic := "orders"
// The KEY decides the partition -> all events for one order stay ordered (sec 4, sec 10).
err := p.Produce(&kafka.Message{
    TopicPartition: kafka.TopicPartition{Topic: &topic, Partition: kafka.PartitionAny},
    Key:            []byte("order-42"),
    Value:          []byte(`{"event":"placed","amount":1999}`),
}, nil)
if err != nil { log.Fatal(err) }

// Producing is async + batched; Flush blocks until queued messages are delivered.
p.Flush(5000)

// Delivery reports tell you the final partition/offset (or an error) per message:
//   for e := range p.Events() { if m, ok := e.(*kafka.Message); ok { ... } }

# Using confluent-kafka (librdkafka). kafka-python / aiokafka are alternatives.
from confluent_kafka import Producer

p = Producer({
    "bootstrap.servers": "localhost:9092",
    "acks": "all",                 # durability: leader + in-sync replicas (sec 5)
    "enable.idempotence": True,    # no duplicates on producer retry (sec 9)
    "linger.ms": 5,                # batch window for throughput
    "compression.type": "zstd",
})

def on_delivery(err, msg):         # async callback: final partition/offset or error
    if err:
        print("delivery failed:", err)
    else:
        print(f"delivered to {msg.topic()}[{msg.partition()}]@{msg.offset()}")

# The KEY decides the partition -> all events for one order stay ordered (sec 4, sec 10).
p.produce(
    "orders",
    key=b"order-42",
    value=b'{"event":"placed","amount":1999}',
    on_delivery=on_delivery,
)
p.flush()                          # block until queued messages are delivered

Consumer membaca record dari partisi. Abstraksi yang kuat consumer group: satu set consumer berbagi group ID yang secara kooperatif membagi partisi topic di antara mereka supaya setiap partisi dibaca tepat satu consumer dalam group. Tambah consumer ke group dan Kafka rebalance, menetapkan ulang partisi untuk menyebar beban. Begitulah Anda scaling konsumsi horizontal, dan ini mekanisme di balik berbagi-kerja dan broadcast.

c, _ := kafka.NewConsumer(&kafka.ConfigMap{
    "bootstrap.servers": "localhost:9092",
    "group.id":          "billing",        // the consumer GROUP, scale by adding instances
    "auto.offset.reset": "earliest",       // where to start if no committed offset (sec 8)
    "enable.auto.commit": false,           // we'll commit manually for at-least-once (sec 9)
})
defer c.Close()
c.Subscribe("orders", nil)                 // Kafka assigns this instance some partitions

for {
    msg, err := c.ReadMessage(-1)          // blocks for the next record
    if err != nil { continue }

    process(msg.Value)                     // do the work FIRST...
    c.CommitMessage(msg)                   // ...THEN commit the offset (at-least-once, sec 9)
}

from confluent_kafka import Consumer

c = Consumer({
    "bootstrap.servers": "localhost:9092",
    "group.id": "billing",                 # the consumer GROUP, scale by adding instances
    "auto.offset.reset": "earliest",       # where to start if no committed offset (sec 8)
    "enable.auto.commit": False,           # commit manually for at-least-once (sec 9)
})
c.subscribe(["orders"])                    # Kafka assigns this instance some partitions

try:
    while True:
        msg = c.poll(1.0)                  # wait up to 1s for the next record
        if msg is None:
            continue
        if msg.error():
            print("error:", msg.error()); continue

        process(msg.value())               # do the work FIRST...
        c.commit(msg)                      # ...THEN commit the offset (at-least-once, sec 9)
finally:
    c.close()                              # leave the group cleanly -> triggers a rebalance

Offset posisi record di partisinya (bagian 3). Tugas consumer melacak offset mana yang sudah ia proses, committed offset-nya: supaya saat restart atau rebalance ia melanjutkan dari tempat yang tepat alih-alih membaca ulang semuanya atau melewatkan record. Kafka menyimpan offset committed ini di topic internal (_consumeroffsets), ber-key group + partisi. Celah antara offset terbaru di partisi dan committed offset group adalah consumer lag: metrik kesehatan terpenting tunggal untuk consumer (bagian 19).

Kapan Anda commit menentukan jaminan Anda

Pilihan antara auto-commit (Kafka secara berkala commit di latar) dan manual commit (Anda commit eksplisit) sebenarnya pilihan tentang semantik pengiriman (bagian 9). Urutan "proses pesan" versus "commit offset" segalanya: commit setelah memproses dan crash di antara berarti Anda akan memproses ulang (at-least-once); commit sebelum memproses dan crash berarti Anda akan melewatkan (at-most-once). Auto-commit pada timer bisa melakukan entah yang mana tergantung timing, itulah kenapa consumer yang sensitif kebenaran commit manual setelah kerja selesai (seperti kode bagian 7).

Pertanyaan yang harus dijawab setiap sistem pesan terdistribusi: jika hal gagal dan retry, berapa kali sebuah pesan mungkin dikirim? Ada tiga jaminan mungkin, dan Kafka bisa memberi Anda salah satunya tergantung konfigurasi, jadi Anda harus memilih secara sadar berdasarkan apa yang bisa ditoleransi pemrosesan Anda.

-- The consumer may see the same event twice on retry/rebalance.
-- Make the write idempotent so a duplicate is a no-op:

-- (a) dedupe by a unique event id
INSERT INTO processed_events (event_id) VALUES ($1)
ON CONFLICT (event_id) DO NOTHING;        -- second delivery inserts nothing
-- ...only do the side effect if the insert affected a row.

-- (b) or make the effect itself idempotent, upsert the end state, don't increment
INSERT INTO account_balance (account_id, balance) VALUES ($1, $2)
ON CONFLICT (account_id) DO UPDATE SET balance = EXCLUDED.balance;
-- applying the same "balance = 100" twice lands on the same state.

Satu kalimat untuk dihafal: Kafka menjamin urutan dalam partisi, dan tidak di tempat lain. Record di partisi P dikirim ke consumer dalam urutan offset persis saat ditulis. Lintas partisi topic yang sama, tidak ada urutan global, record saling bersisip arbitrer. Ini bukan keterbatasan yang harus dikerjakan melainkan harga langsung paralelisme tingkat partisi (bagian 4): Anda bisa punya urutan total, atau skala horizontal, tapi tidak keduanya sekaligus untuk stream yang sama.

Karena record dipertahankan setelah dibaca (bagian 2), Kafka butuh aturan kapan menghapusnya, kalau tidak log tumbuh selamanya. Ada dua kebijakan pembersihan, dan mereka menjawab kebutuhan berbeda. Retensi waktu/ukuran (default) menyimpan record selama jendela, katakanlah 7 hari atau 50 GB per partisi, lalu menghapus yang tertua. Kompaksi log lebih cerdas: ia menyimpan record terbaru untuk tiap key dan mengumpulkan versi lama key itu, mengubah log menjadi snapshot yang terus diperbarui dari "nilai saat ini per key."

Kafka sendiri memperlakukan nilai record sebagai byte buram, ia tidak tahu atau peduli isinya. Kebebasan itu jebakan di skala: jika producer dan consumer tidak setuju pada bentuk payload, producer yang mengubah field diam-diam memecah setiap consumer hilir (bahaya contract-drift yang diperingatkan bab gRPC dan serialisasi, kini tersebar lintas banyak tim independen). Perbaikannya skema untuk tiap topic plus Schema Registry yang menyimpan skema, menetapkan ID, dan menegakkan kompatibilitas saat mereka berevolusi.

Format & kompatibilitas

Format serialisasi umum Avro (pasangan tradisional Kafka, ringkas dengan kisah evolusi skema kaya), Protobuf (IDL yang sama dengan bab gRPC, makin populer), dan JSON Schema (terbaca, lebih besar). Registry menegakkan mode kompatibilitas: biasanya kompatibilitas backward, artinya consumer baru bisa membaca data lama: Anda boleh menambah field opsional dan menghapus yang punya default, tapi tidak boleh mengganti nama atau mengubah tipe field. Ini persis disiplin perubahan aditif dari bab gRPC (bagian 04 di sana: nomor field, jangan pernah pakai ulang) dan versioning REST, ditegakkan otomatis oleh server.

Kafka substrat untuk event-driven architecture (EDA), tempat layanan berkomunikasi dengan memancarkan dan bereaksi terhadap event alih-alih saling memanggil langsung. Alih-alih service order memerintah service email, inventaris, dan analitik (kopling ketat, service order harus kenal semuanya), ia cukup mengumumkan "OrderPlaced" ke topic, dan service mana pun yang tertarik berlangganan. Producer tidak tahu, atau peduli, siapa yang mengonsumsi. Ini pembayaran dalam dari decoupling log (bagian 1): Anda menambah consumer baru tanpa menyentuh producer.

Dua pola lanjutan yang dimungkinkan log, sering dikacaukan, sering dipasangkan. Event sourcing menyimpan state sebagai urutan event yang menghasilkannya alih-alih hanya snapshot saat ini: alih-alih baris balance = 100, Anda menyimpan Deposited 60, Deposited 50, Withdrew 10, dan menurunkan saldo dengan memutar ulangnya. Log immutable terurut yang dipertahankan Kafka (bagian 3) event store alami. CQRS (Command Query Responsibility Segregation) memisahkan model tulis dari satu atau lebih model baca yang dioptimalkan untuk query.

Manfaatnya nyata: jejak audit lengkap (setiap perubahan fakta tercatat, emas untuk finansial dan kepatuhan), kemampuan membangun ulang state di titik masa lalu mana pun dengan memutar ulang ke offset, dan banyak model baca khusus yang masing-masing bisa dibangun ulang dari log yang sama (kompaksi, bagian 11, menyediakan snapshot untuk menghindari memutar ulang dari awal zaman).

Masalah halus dan penting di sistem event-driven: saat service harus memperbarui database-nya dan menerbitkan event, melakukannya sebagai dua operasi terpisah tidak aman. Jika commit DB sukses tapi publish Kafka gagal (atau sebaliknya), sistem Anda menyimpang, order ada tapi tidak ada event "OrderPlaced", atau event menyala untuk order yang di-rollback. Ini masalah dual-write, dan Anda tidak bisa memperbaikinya dengan menukar urutan dua tulis, selalu ada jendela crash di antara keduanya.

Pola outbox menyelesaikannya dengan satu transaksi lokal: tulis perubahan bisnis Anda dan baris "outbox" yang mendeskripsikan event ke dalam transaksi database yang sama, jadi mereka commit secara atomik. Proses relay terpisah lalu membaca baris outbox baru dan menerbitkannya ke Kafka (retry sampai sukses, at-least-once, karenanya consumer tetap idempotent, bagian 9). Cara modern ber-friction-rendah menjalankan relay itu Change Data Capture (CDC): tool seperti Debezium men-tail log transaksi database dan meng-stream perubahan yang di-commit langsung ke Kafka, tanpa polling aplikasi.

BEGIN;

-- 1) the actual business change
INSERT INTO orders (id, customer_id, amount, status)
VALUES ('order-42', 'cust-7', 1999, 'PLACED');

-- 2) the event to publish, written in the SAME transaction -> atomic with (1)
INSERT INTO outbox (id, aggregate, event_type, payload, created_at)
VALUES (gen_random_uuid(), 'order-42', 'OrderPlaced',
        '{"id":"order-42","amount":1999}', now());

COMMIT;   -- both succeed together, or neither does, no dual-write gap

-- A relay (or Debezium CDC on the transaction log) then reads new `outbox`
-- rows and produces them to Kafka, marking each published. Retries are safe
-- because downstream consumers are idempotent (sec 9).

Sejauh ini consumer membaca event satu per satu. Stream processing disiplin menghitung secara berkelanjutan di atas stream, memfilter, mentransformasi, mengagregasi, meng-join, menghasilkan stream turunan baru. Alih-alih "baca event, lakukan satu hal," Anda mengekspresikan query berdiri seperti "hitungan bergulir 5 menit dari pembayaran gagal per merchant" yang diperbarui selamanya saat event tiba. Library Kafka untuk ini Kafka Streams (JVM); ksqlDB menawarkan lapisan mirip SQL, dan Apache Flink kelas berat untuk job besar kompleks.

Kembali ke perbedaan bagian 2 dengan konteks cukup untuk memutuskan dengan baik. Ini pertanyaan yang mengirim orang ke bab task-queues dan kembali: apakah saya mau Kafka atau message queue (RabbitMQ, SQS, dunia Celery/Sidekiq)? Mereka cukup tumpang tindih untuk membingungkan dan cukup berbeda untuk berpengaruh.

Kebanyakan rasa sakit Kafka produksi muncul di sisi consumer. Ini mode kegagalan yang menggigit tim nyata, layak dikenali sebelum mereka page Anda jam 2 pagi.

Menjalankan Kafka dengan baik bermuara pada memantau beberapa sinyal dan mengukur beberapa hal dengan benar. Anda tidak perlu menghafal setiap metrik, tapi harus tahu yang memprediksi masalah.

Keputusan sizing yang benar-benar Anda buat

• Jumlah partisi: men-set paralelisme consumer maksimum dan throughput (bagian 4, bagian 7). Perkirakan dari target throughput dan jumlah consumer puncak; condong sedikit tinggi, tapi tidak liar (tiap partisi punya overhead, dan ribuan per broker menyakitkan). Sulit diubah belakangan, jadi pikirkan ke depan (bagian 20).
• Faktor replikasi: biasanya 3 di produksi: mentoleransi satu kehilangan broker dengan ruang cadangan. Pasangkan dengan min.insync.replicas=2 dan acks=all (bagian 5).
• Retensi: berapa lama event hidup (dan karenanya pemakaian disk dan jendela replay). Set per topic seberapa jauh ke belakang consumer mungkin perlu membaca.

Menarik manual ke penilaian desain. Kafka tool kuat dan tajam; dipakai di tempatnya transformatif, dipakai sebagai message bus generik liabilitas. Beberapa prinsip memisahkan desain Kafka yang baik dari yang menyakitkan.

Prinsip desain

• Modelkan topic di sekitar event/fakta, bukan perintah atau RPC. Topic adalah stream dari "hal yang terjadi" (PaymentSettled), dikonsumsi siapa pun yang peduli, bukan cara menyuruh service spesifik melakukan sesuatu. Jika Anda mendapati ingin request/response, Anda ingin gRPC/REST, bukan Kafka.
• Pilih partition key berdasarkan batas urutan Anda. Key berdasarkan entitas yang event-nya harus tetap terurut (akun, order, user), tapi pada granularitas yang tetap menyebar beban, untuk menghindari partisi panas (bagian 10, bagian 18). Key keputusan per-topic paling konsekuensial.
• Asumsikan at-least-once; bangun consumer idempotent. Jangan mengejar exactly-once end-to-end lintas sistem eksternal (bagian 9). Dedup dengan event ID atau pakai upsert supaya duplikat tidak berbahaya, lebih murah dan lebih kokoh.
• Kelola skema sejak hari pertama. Pakai Schema Registry dengan kompatibilitas backward (bagian 12) supaya tim independen bisa berevolusi dengan aman. Skema topic kontrak.
• Pakai outbox untuk tulis DB-dan-event. Jangan pernah dual-write; buat event atomik dengan data dan relay (bagian 15).
• Ukur partisi untuk puncak di depan. Repartisi memecah urutan key (bagian 4), jadi rencanakan pertumbuhan alih-alih bereaksi padanya.

Seluruh manual dipadatkan menjadi yang Anda raih saat tertekan.