Pola Event-Driven Architecture dengan Kafka dan PHP Worker

Suar ngorok server fan di rak data malam itu berpadu dengan suara ketukan jari di atas meja ruang meeting. Layar monitor menampilkan grafik pemonitoran Datadog yang menukik tajam ke zona merah. "Database kita hampir jebol gara-gara webhook pihak ketiga yang masuk bersamaan 5.000 req/s," keluh Umar, lead backend developer kami, sambil mengusap wajahnya yang kelelahan. Saat itu, arsitektur monolitik berbasis sinkronus yang melayani aplikasi PHP kami benar-benar berlutut. Setiap kali ada order masuk, sistem harus memanggil API payment gateway, mengirim email lewat Postfix lokal, memperbarui stok di MySQL, dan mentrigger analitik secara bersamaan di dalam satu HTTP request siklus hidup PHP-FPM. Pertanyaannya bukan lagi apakah sistem ini akan tumbang, melainkan kapan pastinya ia akan mati total. Di sinilah perdebatan sengit dimulai antara mempertahankan pola konvensional atau beralih total ke ekosistem asinkronus menggunakan Apache Kafka dan PHP worker.

Sebelum kita masuk ke arena pertempuran, mari kita lihat bagaimana kedua pendekatan ini berhadap-hadapan secara langsung di atas kertas dalam matriks performa nyata di lapangan.

[!WARNING] Jangan pernah mencoba memindahkan seluruh logika aplikasi ke event-driven tanpa memetakan domain event dengan benar. Salah mendefinisikan event justru akan menciptakan distributed monolith yang jauh lebih mengerikan untuk didebug daripada monolitik biasa.

1. Pertarungan Filosofi: Dua Cara Pandang Berbeda dalam Memecahkan Masalah

Filosofi klasik web development mengajarkan kita untuk memperlakukan request HTTP sebagai sebuah transaksi instan: klien bertanya, server berpikir keras, lalu server menjawab. Pendekatan ini sangat indah saat aplikasi masih seumur jagung. Namun, ketika skala bisnis menuntut integrasi dengan puluhan third-party service seperti AWS S3, Redis caching, Mailgun, dan webhook partner, model "tunggu sampai selesai" menjadi bumerang.

Di satu sisi, ada kubu yang bersikeras bahwa PHP itu dirancang untuk proses stateless berumur pendek. "Kenapa harus repot membuat daemon worker yang berjalan terus-menerus dan rentan terhadap memory leak?" begitu argumen mereka. Di sisi lain, kebutuhan skala enterprise memaksa kita untuk memisahkan domain "penerimaan data" dari domain "pengolahan data".

Di sinilah Apache Kafka masuk sebagai Event Streaming Platform yang bertindak sebagai sumber kebenaran tunggal (single source of truth) yang persisten. Kafka tidak peduli apakah konsumer PHP Anda sedang lambat atau bahkan mati; pesan tetap aman tersimpan di dalam disk dengan retensi waktu yang bisa diatur. PHP worker kemudian bertindak sebagai stream processor yang mengambil pesan-pesan tersebut secara asinkronus sesuai kapasitas mesin. Perubahan filosofi ini mengubah paradigma dari "saya harus selesaikan sekarang" menjadi "saya catat dulu, saya proses secepat kemampuan server".

Transisi dari ketakutan akan proses background yang terputus-putus menuju orkestrasi worker yang tangguh membawa kita langsung ke dapur pacu implementasi teknisnya, di mana kita harus berhadapan dengan kenyataan pahit menulis kode produsen dan konsumer di dunia PHP yang secara historis tidak diciptakan untuk proses long-running daemon.

2. Ronde 1: Ergonomi Menulis Kode & Pengalaman Konfigurasi Sehari-hari

Bicara soal PHP, pustaka standar untuk berinteraksi dengan Kafka adalah librdkafka yang dibungkus lewat ekstensi PECL rdkafka. Berbeda dengan Node.js atau Go yang memiliki pustaka asinkronus bawaan yang sangat kaya, menulis PHP worker untuk Kafka membutuhkan kedisiplinan tingkat tinggi karena sifat bahasa PHP yang shared-nothing per request.

Mari kita bedah implementasi nyata bagaimana sebuah Producer mengirimkan event transaksi ke Kafka, dan bagaimana Consumer memprosesnya di balik layar menggunakan Supervisor sebagai penjaga gawang proses.

<?php
// producer.php - Mengirim event transaksi dengan aman ke Kafka cluster
declare(strict_types=1);

use RdKafka\Producer;
use RdKafka\Conf;

$conf = new Conf();
// Konfigurasi broker dan optimasi pengiriman
$conf->set('metadata.broker.list', 'kafka1.internal:9092,kafka2.internal:9092');
$conf->set('compression.codec', 'lz4');
$conf->set('queue.buffering.max.ms', '50'); // Batching delay untuk throughput tinggi

$producer = new Producer($conf);
$topic = $producer->newTopic('order-created-events');

$payload = json_encode([
    'order_id' => 'ORD-2023-99812',
    'customer_id' => 45920,
    'amount' => 1500000,
    'timestamp' => time()
]);

// Kirim pesan dengan partisi berdasarkan customer_id agar berurutan
$topic->produce(RD_KAFKA_PARTITION_UA, 0, $payload, (string) 45920);

// Pastikan semua pesan terkirim sebelum skrip mati
$result = $producer->flush(5000);
if (RD_KAFKA_RESP_ERR_NO_ERROR !== $result) {
    throw new \RuntimeException("Gagal mengirim pesan ke Kafka: " . rd_kafka_err2str($result));
}

echo "Event order berhasil dipublikasikan secara asinkronus.\n";

Di sisi lain, bagian paling menantang dari PHP worker bukanlah menulis kodenya, melainkan bagaimana menjaga agar proses konsumsi pesan tidak berhenti di tengah jalan akibat memory leak atau kegagalan koneksi jaringan. PHP tidak dirancang untuk berjalan selama berhari-hari tanpa membersihkan memori internal secara otomatis. Oleh karena itu, kita membutuhkan struktur Consumer yang cerdas dan membatasi jumlah pesan yang diproses sebelum worker melakukan graceful restart.

<?php
// worker.php - Long-running consumer dengan manajemen memori yang ketat
declare(strict_types=1);

use RdKafka\KafkaConsumer;
use RdKafka\Conf;

$conf = new Conf();
$conf->set('metadata.broker.list', 'kafka1.internal:9092');
$conf->set('group.id', 'order-processing-group');
$conf->set('auto.offset.reset', 'earliest');
$conf->set('enable.auto.commit', 'false'); // Manual commit untuk mencegah data loss

$consumer = new KafkaConsumer($conf);
$consumer->subscribe(['order-created-events']);

$maxMessagesPerProcess = 1000;
$processedCount = 0;

echo "PHP Kafka Worker siap mendengarkan event...\n";

while (true) {
    $message = $consumer->consume(120); // Timeout 120ms
    
    switch ($message->err) {
        case RD_KAFKA_RESP_ERR_NO_ERROR:
            try {
                processOrderPayload($message->payload);
                // Commit offset secara manual setelah sukses diproses
                $consumer->commit($message);
                $processedCount++;
             \} catch (\Throwable $e) {
                // Catat error dan arahkan ke Dead Letter Queue (DLQ)
                sendToDeadLetterQueue($message->payload, $e->getMessage());
                $consumer->commit($message); // Komit agar tidak macet di offset yang sama
            }
            break;
            
        case RD_KAFKA_RESP_ERR__PARTITION_EOF:
        case RD_KAFKA_RESP_ERR__TIMED_OUT:
            break;
            
        default:
            throw new \Exception($message->errstr(), $message->err);
    }

    // Preventif terhadap memory leak khas PHP
    if ($processedCount >= $maxMessagesPerProcess) {
        echo "Mencapai batas maksimal pesan, melakukan restart worker...\n";
        exit(0); // Supervisor akan otomatis menghidupkan kembali proses ini
    }
}

function processOrderPayload(string $jsonPayload): void {
    $data = json_decode($jsonPayload, true);
    // Proses bisnis inti di sini (panggil database, kirim email, dll)
    // Contoh: DB::table('orders')->insert($data);
}

function sendToDeadLetterQueue(string $payload, string $error): void {
    // Implementasi pengiriman payload gagal ke topik DLQ Kafka
}

Agar skrip PHP CLI di atas dapat hidup abadi dan tahan banting, kita mengandalkan konfigurasi Supervisor di server produksi kita. Berikut adalah file konfigurasi valid yang biasa kami gunakan di lingkungan Linux production:

[program:kafka-order-worker]
command=php /var/www/html/artisan worker:consume-orders
process_name=%(program_name)s_%(process_num)02d
numprocs=4
autostart=true
autorestart=true
user=www-data
redirect_stderr=true
stdout_logfile=/var/log/supervisor/kafka-order-worker.log
stopwaitsecs=3600

[!TIP] Selalu atur numprocs sesuai dengan jumlah partisi topik Kafka Anda. Jika partisi topik Anda ada 4, maka numprocs=4 di Supervisor akan memberikan performa paralel yang paling optimal tanpa memperebutkan kunci partisi yang sama.

3. Ronde 2: Uji Ketahanan di Bawah Gempuran Beban Ekstrem

Teori dan kode di atas tampak sangat rapi di atas editor teks, tetapi bagaimana perilaku mereka di arena nyata ketika diuji menggunakan perkakas stress testing seperti k6 atau wrk? Kami melakukan simulasi pengiriman 50.000 request HTTP POST secara serentak ke endpoint API PHP yang bertugas membuang data (produce) ke Kafka, sementara 4 proses worker PHP di belakang bekerja keras mengonsumsinya.

Hasilnya di luar dugaan. Pada arsitektur lama berbasis sinkronus, server langsung mengalami Connection Timed Out begitu jumlah concurrent connection menyentuh angka 1.200, karena koneksi MySQL kehabisan pool akibat tertahan oleh proses eksternal API. Namun, dengan arsitektur Kafka + PHP Worker, endpoint HTTP bertindak sebagai produsen super ringan yang merespons klien dalam rata-rata 8 milidetik. Angka CPU pada web server Nginx dan PHP-FPM hampir tidak bergeming di bawah 15%.

Titik jenuh justru bergeser ke arah disk I/O broker Kafka dan kapasitas consumer group rebalancing ketika salah satu worker dimatikan secara paksa. Di sinilah letak keunggulan asinkronus: lonjakan trafik sebesar apapun tidak akan merusak database utama Anda, karena Kafka bertindak sebagai peredam kejut (shock absorber) yang sangat tangguh. Pesan antre dengan tertib di dalam commit log Kafka, menunggu giliran untuk dikunyah oleh PHP worker sesuai kapasitas pemrosesan server.

Namun, memproses data secara massal tidak lepas dari risiko data korup atau kegagalan sistem pihak ketiga. Pertanyaan selanjutnya adalah: apa yang terjadi ketika sebuah pesan gagal diproses berulang kali?

4. Ronde 3: Konsumsi Sumber Daya Server & Efisiensi Biaya Nyata

Dari sisi finansial infrastruktur, peralihan ke Kafka memberikan dampak efisiensi yang signifikan. Sebelumnya, untuk melayani 3.000 request per detik, kami harus menyewa setidaknya 6 buah instance server berukuran besar (c5.2xlarge di AWS) hanya untuk menampung koneksi PHP-FPM yang menggantung lama menunggu proses eksternal.

Setelah memisahkan beban kerja menggunakan Kafka dan PHP worker yang berjalan di atas instance yang lebih kecil (t3.medium), kebutuhan server turun drastis. Kita hanya membutuhkan 2 node Kafka berukuran sedang untuk broker cluster dan 2 instance worker dedicated. RAM per PHP worker sangat stabil karena batasan maxMessagesPerProcess yang membersihkan memori secara berkala, menghindari momok memory leak yang sering menjadi penyakit kronis aplikasi PHP skala besar.

Meski demikian, kompleksitas operasional meningkat. Tim DevOps harus memantau kesehatan Zookeeper/KRaft quorum Kafka, memonitor consumer lag secara berkala, dan memastikan tidak ada pesan yang terjebak di Dead Letter Queue tanpa penanganan manusia.

5. Kapan Wajib Menggunakan Apache Kafka & PHP Worker

Anda wajib segera meninggalkan pola sinkronus murni dan beralih menggunakan Apache Kafka bersama PHP worker jika:

1. Integrasi Layanan Pihak Ketiga yang Lambat: Aplikasi Anda sering melakukan panggilan API eksternal (Payment Gateway, SMS/WhatsApp Sender, AI API) yang memakan waktu lebih dari 500ms per request.
2. Ledakan Trafik Musiman (Flash Sale): Bisnis Anda bergerak di e-commerce atau ticketing yang mengalami lonjakan trafik ekstrem secara tiba-tiba, di mana database utama tidak boleh sampai lumpuh.
3. Sistem Multi-Consumer (Fan-out): Satu aksi pengguna (misal: pendaftaran akun) harus memicu banyak proses berbeda secara paralel: mengirim email sambutan, mencatat analitik ke Data Warehouse, membuat folder penyimpanan S3, dan mendaftarkan kupon referral.

6. Kapan Wajib Menggunakan Pendekatan Sinkronus Tradisional

Jangan gunakan Kafka jika proyek Anda masuk dalam kategori berikut karena hanya akan menambah beban overhead operasional yang tidak perlu:

1. Aplikasi CRUD Skala Kecil hingga Menengah: Sistem internal perusahaan, landing page, atau aplikasi dengan jumlah pengguna aktif harian di bawah 10.000 orang.
2. Konsistensi Data Instan yang Mutlak (Strong Read-After-Write Consistency): Jika pengguna wajib melihat perubahan data secara langsung pada halaman yang sama detik itu juga tanpa jeda sepersekian detik pun, proses asinkronus justru akan membuat UX terasa patah-patah.
3. Keterbatasan Sumber Daya Tim DevOps: Mengelola kluster Kafka membutuhkan keahlian khusus. Jika tim Anda hanya berisi sedikit developer tanpa spesialis infrastruktur, penggunaan antrean yang lebih ringan seperti Redis Queue (php-resque atau Laravel Horizon) jauh lebih masuk akal.

7. Keputusan Akhir: Rekomendasi Jujur untuk Tim Engineering

Arsitektur bukanlah ajang perlombaan untuk menggunakan teknologi paling rumit atau paling mahal. Apache Kafka dan PHP worker bukanlah peluru perak (silver bullet) yang bisa menyelesaikan segala masalah performa aplikasi web Anda. Ia adalah alat berat untuk medan perang berskala enterprise.

Jika sistem Anda saat ini mulai mengalami kelambatan karena tumpukan proses background yang merusak siklus hidup request HTTP, mulailah dengan langkah moderat: pisahkan tugas berat dari controller menggunakan Redis Queue. Namun, ketika skala bisnis Anda menuntut ketahanan absolut, kemampuan replay message, dan integrasi lintas sistem lintas bahasa, maka melompat ke Apache Kafka dengan armada PHP worker yang dikawal ketat oleh Supervisor adalah keputusan terbaik yang akan menyelamatkan karier dan kewarasan Anda sebagai seorang engineer.