Design Distributed Message Queue

Prompt latihan

1. Problem Statement, Functional Requirements, and Scale Assumptions

   Tentukan ruang lingkup distributed message queue: producer mem-publish pesan ke topic bernama, consumer men-subscribe topic dalam consumer group (setiap pesan dikirim ke tepat satu consumer dalam sebuah group), pesan diretensi untuk window yang dapat dikonfigurasi, dan consumer dapat mengulang (replay) dari offset mana pun. Kecualikan secara eksplisit: exactly-once delivery sebagai baseline (mulai dengan at-least-once), schema registry, stream processing (Kafka Streams/Flink), replikasi cross-datacenter, dan otorisasi ACL consumer group. Nyatakan asumsi skala: throughput pesan (jutaan/detik), jumlah topic, jumlah consumer group, ukuran pesan rata-rata, periode retensi (hari), dan replication factor.

2. Non-Functional Requirements

   Tentukan NFR utama: durabilitas pesan (tidak ada kehilangan data saat broker gagal, replication factor dan commit policy apa yang menjaminnya?), jaminan pengurutan (FIFO per-partition adalah standar, apa implikasinya terhadap routing berbasis key?), semantik delivery (baseline at-least-once: sebuah pesan mungkin dikirim lebih dari sekali tetapi tidak pernah hilang; bandingkan dengan exactly-once yang menambah biaya signifikan), latensi publish (berapa lama dari producer send() hingga pesan tersedia untuk dikonsumsi, target P99 < 10ms untuk producer in-cluster), dan monitoring consumer lag (bagaimana consumer tahu jika mereka tertinggal, dan alert apa yang dibutuhkan?).

3. Quantitative Analysis

   Estimasikan: throughput pesan per broker (total 1 juta pesan/s, 100 broker = 10 ribu pesan/s/broker × 1KB rata-rata = 10MB/s throughput tulis, muat pada NVMe SSD modern), storage untuk window retensi (1 juta pesan/s × 1KB × 86400s × 7 hari × 3 replika = ~1,8PB total, memerlukan penentuan ukuran partition yang cermat), bandwidth replikasi (setiap tulis direplikasi 3× = 30MB/s per broker untuk follower), storage offset consumer group (10 ribu consumer group × 1000 partition × 8 byte/offset = 80MB, dapat diabaikan), dan penentuan jumlah partition (1 juta pesan/s / batas throughput 100 ribu pesan/s per partition = minimum 10 partition untuk throughput).

4. API Design

   Tentukan operasi API untuk: PRODUCE (topic, partition_key, payload, headers, SDK producer mem-batch dan mengirim; server menetapkan offset dan mengembalikannya ke producer), CONSUME (group_id, topic, partition, fetch_offset, max_bytes, mengembalikan batch pesan beserta offset), COMMIT offset (group_id, topic, partition, offset, menandai pesan sudah diproses; memungkinkan restart dari posisi yang di-commit), CREATE topic (name, partition_count, replication_factor, retention_ms), dan DESCRIBE consumer group (group_id, mengembalikan penugasan partition dan lag per partition). Jelaskan bagaimana partition_key menggerakkan penugasan partition (hash(key) % partition_count), bagaimana produce/consume batch meningkatkan throughput, dan bagaimana idempotent produce mencegah duplikasi pesan saat retry.

5. High-Level Design

   Usulkan komponen utama: broker cluster (menerima request produce, meng-append ke partition log, melayani request consume), partition manager (menetapkan partition leader ke broker, memelihara pemetaan partition-broker), replication engine (leader partition mereplikasi ke follower replica; commit memerlukan acknowledgment dari kuorum ISR), consumer group coordinator (mengelola keanggotaan group, menetapkan partition ke consumer, melacak offset yang di-commit), offset store (storage offset yang durable per consumer group dan partition), dan metadata service (topologi cluster, konfigurasi topic, kepemimpinan partition, diimplementasikan via ZooKeeper atau konsensus Raft). Jelaskan write path: producer → leader broker → append ke log → replikasi ke follower → commit → kembalikan offset ke producer.

6. Additional High-Level Design Prompts

   Bahas tiga area lanjutan: (1) Pemilihan partition leader, ketika broker yang meng-host partition leader crash, bagaimana leader baru dipilih? Daftar ISR (in-sync replica) berisi semua follower yang caught up dalam ambang batas replication lag; controller memilih anggota ISR pertama yang tersedia sebagai leader baru; apa yang terjadi pada pesan yang telah di-ack oleh leader yang crash tetapi belum direplikasi ke anggota ISR mana pun? (2) Strategi commit offset consumer, auto-commit (offset di-commit otomatis setiap N ms; risiko: pesan diproses tetapi di-commit sebelum aplikasi memprosesnya vs. pesan di-commit tetapi tidak diproses) vs. manual commit (consumer secara eksplisit meng-commit setelah pemrosesan; memungkinkan pemrosesan exactly-once bila dipasangkan dengan output idempoten); (3) Kompaksi pesan vs. retensi berbasis waktu, log compaction hanya meretensi pesan terbaru per key (berguna untuk topic changelog, mis. update profil pengguna); retensi berbasis waktu menghapus semua pesan yang lebih tua dari N hari; kebijakan retensi mana yang cocok untuk use case mana?

7. Deep Dives

   Deep dive ke tiga area: (1) Jaminan pengurutan, pengurutan per-partition: pesan dengan key yang sama selalu menuju partition yang sama (routing berbasis hash); di dalam sebuah partition, log bersifat append-only sehingga pengurutan dipertahankan; consumer membaca partition log dalam urutan offset; jaminan: FIFO per-key, jika Anda butuh pengurutan lintas-partition, tidak ada solusi native, Anda harus menggunakan satu partition (bottleneck throughput) atau me-merge saat consumer; pengurutan saat leader failover: jika leader crash setelah menulis ke partition log tetapi sebelum mereplikasi ke ISR, dan leader baru dipilih dari ISR, pesan yang belum direplikasi hilang meskipun producer menerima ack (mode acks=1); dengan acks=all (kuorum ISR) dan min.insync.replicas=2, tidak ada pesan yang telah di-ack yang hilang; (2) Rebalancing consumer group, pemicu: anggota join, leave, atau heartbeat timeout; rebalance klasik (eager): semua consumer berhenti mengonsumsi, penugasan partition direset, semua consumer join ulang, menyebabkan consumer lag selama rebalance; rebalance cooperative (incremental): hanya partition yang sedang dimigrasi yang dicabut; partition yang tidak dimigrasi terus dikonsumsi selama rebalance; keanggotaan group statis: tetapkan member_id persisten ke consumer; jika ia reconnect dalam session.timeout, penugasan partition-nya dipertahankan, menghindari rebalance pada gangguan jaringan singkat; (3) Exactly-once delivery, idempotent producer: setiap producer diberi producer_id; setiap pesan membawa sequence number; broker men-deduplikasi pesan yang dikirim ulang dalam window sesi; produce-consume transaksional: producer secara atomik mem-publish pesan output dan meng-commit offset consumer dalam sebuah transaksi; broker menahan output hingga transaksi commit; consumer hanya membaca offset yang di-commit; biaya performa: tulis transaksional menambah latensi ~2-5ms per transaksi; throughput berkurang ~20%, dapat diterima untuk pemrosesan pembayaran, tidak dapat diterima untuk analitik throughput tinggi.

8. Final Review Handoff Readiness

   Ringkas keputusan desain utama: replikasi kuorum-ISR (acks=all, min.insync.replicas=2), pengurutan FIFO per-partition via routing berbasis key, rebalancing cooperative incremental, manual offset commit untuk keandalan, dan exactly-once via idempotent producer + semantik transaksional. Soroti dua pertanyaan terbuka terbesar yang tersisa (celah pengurutan pemilihan leader, ketika leader terpilih tertinggal N pesan saat failover, apakah N pesan tersebut hilang permanen atau dapat dipulihkan dari leader yang gagal jika ia kembali, dan rebalance storm, apa yang terjadi ketika sebuah consumer group dengan 100 anggota semuanya timeout bersamaan dan memicu rebalance beruntun) dan usulkan rollout bertahap: at-least-once delivery dulu, lalu cooperative rebalancing, lalu exactly-once untuk topic yang kritis-pembayaran.

Preview solusi

Solution: Design Distributed Message Queue Framing Problem Sebuah distributed message queue men-decouple producer dari consumer pada skala besar: producer mempublikasikan message ke topic bernama, consumer melakukan subscribe dalam group (setiap message dikirimkan ke tepat satu consumer per group), dan message diretensi untuk replay. Dalam scope: Pub/sub ber…