Wawancara data engineering: Kinesis on-demand atau provisioned capacity?

Perintah dan konteks

Anda mengelola platform data yang mengumpulkan (ingest) event pengguna untuk beberapa konsumen real-time. Trafik stabil di sebagian besar waktu sepanjang hari dan melonjak selama masa kampanye. Bisnis tidak dapat mentolerir pelambatan (throttling) yang berkelanjutan, namun tidak ingin membayar kapasitas di muka untuk periode sepi. Asumsikan Anda dapat membaca throughput produser, latensi baca, throttling, dan consumer lag, serta dapat beralih mode kapasitas selama jendela pemeliharaan (maintenance window).

Apa yang dievaluasi pewawancara

Pewawancara menguji apakah Anda memahami bahwa mode kapasitas mengubah tanggung jawab operasional dan biaya, bukan semantik pengiriman (delivery semantics). Jawaban yang kuat menggunakan lonjakan historis dan bentuk burst untuk memutuskan apakah penskalaan otomatis memberikan nilai tambah, lalu memeriksa batas per-shard, jumlah konsumen, percobaan ulang (retry), dan pemulihan lag. Jawaban yang lemah hanya mengatakan untuk memilih on-demand setiap kali trafik bervariasi.

Klarifikasi untuk ditanyakan terlebih dahulu

• Berapa lama lonjakan berlangsung, dan apakah dapat diprediksi? Lonjakan singkat yang tidak dapat diprediksi mendukung pengelolaan kapasitas otomatis.
• Apakah penulisan dan pembacaan dibatasi pada saat yang sama? Ukur bita, rekaman, pembacaan, dan perilaku konsumen secara terpisah.
• Apakah ada batas atas biaya yang ketat atau anggaran kapasitas? Trafik yang stabil dengan anggaran ketat lebih mudah dioptimalkan dalam mode provisioned.
• Apakah konsumen berbagi throughput atau memerlukan pembacaan khusus? Beberapa konsumen mengubah kuota baca dan biaya.
• Bisakah tim mentolerir transisi status yang singkat? Pengalihan mode dan percobaan ulang burst memerlukan runbook yang eksplisit.

Kerangka jawaban 30 detik

"Saya akan mengukur MB/s penulisan per jam, laju rekaman, MB/s pembacaan, lag, dan throttling, memisahkan lonjakan yang dapat diprediksi dari lonjakan tiba-tiba (burst). Trafik yang stabil dan dapat diprediksi dapat menggunakan provisioned capacity dengan jadwal penskalaan; perubahan yang cepat atau tidak dapat diprediksi lebih cocok menggunakan on-demand, tetapi saya akan memvalidasi ramp-up, kuota, dan biaya. Kedua pilihan harus memenuhi batasan (guardrails) untuk throttling, pemulihan lag, latensi end-to-end, dan pengeluaran bulanan."

Jawaban mendalam langkah demi langkah

1. Bangun baseline kapasitas. Agregasikan penulisan dan pembacaan per menit, catat P50, P95, P99, durasi lonjakan, dan partition key yang panas (hot partition keys); nilai rata-rata menyembunyikan burst.
2. Periksa batas throughput. AWS mendokumentasikan batas shard default sebesar 1 MB/s atau 1.000 rekaman per detik untuk penulisan dan 2 MB/s untuk pembacaan. Konversikan ukuran rekaman dan batching ke dalam satuan bita maupun rekaman.
3. Pilih mode. Gunakan provisioned capacity dengan rencana penskalaan untuk beban yang stabil; pilih on-demand jika beban berubah dengan cepat atau sulit diprediksi, dan catat latensi penyesuaian otomatis.
4. Modelkan konsumen. Pembacaan bersama, enhanced fan-out, percobaan ulang, dan pemrosesan duplikat memengaruhi kuota baca. Consumer lag harus diperhitungkan dalam perencanaan kapasitas, bukan hanya metrik produser.
5. Modelkan biaya. Untuk mode provisioned, sertakan shard-hours dan ruang cadangan (headroom) penskalaan. Untuk on-demand, sertakan throughput aktual dan penagihan saat lonjakan, ditambah pemutaran ulang (replay) dan penulisan ganda saat burst.
6. Lakukan uji coba dan rollback. Alihkan satu stream non-kritis, pantau throttling, pemulihan lag, latensi P99, dan pengeluaran bulanan. Jika sebuah batasan terlanggar, kembalikan ke mode yang telah divalidasi sambil mempertahankan urutan dan perilaku percobaan ulang.

Alternatif lainnya mencakup membagi hot partition key, melakukan batching pada penulisan, memperkecil ukuran event, melakukan buffering dengan Firehose, atau melakukan pra-skala untuk kampanye yang dapat diprediksi. Mode kapasitas tidak dapat memperbaiki kunci yang timpang, konsumen yang lambat, atau percobaan ulang tanpa batas.

Contoh jawaban model

"Saya akan memeriksa kurva penulisan dan pembacaan per menit selama 30 hari, menghitung P95/P99, durasi lonjakan, dan ketimpangan partition key. Saya akan mengonversikan ukuran rekaman melalui batas shard AWS ke dalam MB/s penulisan dan laju rekaman, kemudian memeriksa throughput konsumen bersama dan pemulihan lag. Untuk lonjakan yang dapat diprediksi dan berlangsung berjam-jam, saya akan menggunakan provisioned capacity dan melakukan pra-skala sebelum kampanye. Untuk lonjakan singkat yang tidak terduga, saya akan menguji coba on-demand pada stream non-kritis dengan throttling di bawah 0,1%, pemulihan lag p99 di bawah 5 menit, latensi end-to-end dalam batas 20% dari baseline, dan batas biaya bulanan. Saya akan memantau partisi yang panas dan duplikasi di kedua mode; mengubah mode kapasitas tidak boleh menyembunyikan akar masalah."

Kesalahan umum

• Kesalahan: Memperkirakan dari rata-rata throughput → Mengapa gagal: Burst dan hot key menyebabkan pelambatan lokal → Solusi: Gunakan P95/P99, durasi lonjakan, dan distribusi kunci.
• Kesalahan: Menganggap on-demand sebagai throughput tak terbatas → Mengapa gagal: Kuota layanan dan ramp-up tetap berpengaruh → Solusi: Validasi perilaku ramp-up, kuota, dan pengujian burst.
• Kesalahan: Hanya menghitung biaya produser → Mengapa gagal: Konsumen, percobaan ulang, dan replay memperbesar throughput → Solusi: Bangun skenario biaya end-to-end.
• Kesalahan: Mengabaikan semantik pengiriman → Mengapa gagal: Mode kapasitas tidak menghilangkan risiko setidaknya sekali (at-least-once) dan pemrosesan duplikat → Solusi: Pertahankan idempoten, checkpoint, dan pemulihan lag.

Pertanyaan lanjutan dan tanggapan

On-demand masih mengalami throttling; apa yang Anda sesuaikan terlebih dahulu?

Pisahkan antara kekurangan throughput total, hot partition key, dan konsumen yang tertinggal. Periksa laju rekaman, distribusi kunci, dan event penskalaan sebelum memilih backoff, pemartisian ulang, atau menambah lebih banyak konsumen.

Kapan provisioned capacity lebih murah?

Ketika penulisan dan pembacaan stabil, lonjakan dapat dijadwalkan, dan utilisasi tetap tinggi, modelkan shard-hours dan headroom penskalaan. Jangan hanya membandingkan harga satuan.

Bagaimana jika trafik kampanye melonjak sepuluh kali lipat?

Verifikasi kuota on-demand dan perilaku ramp-up historis terlebih dahulu. Lakukan pra-skala untuk kampanye yang dapat diprediksi, tambahkan backoff produser dan peringatan lag, serta tentukan degradasi fitur untuk event non-kritis.

Bagaimana Anda membuktikan bahwa pilihan tersebut benar?

Bandingkan throttling, p99 pemulihan lag, latensi end-to-end, tingkat duplikasi, dan biaya bulanan sebelum dan sesudah uji coba dengan definisi yang sama. Perluas implementasi setelah dua siklus bisnis memenuhi batasan yang ditentukan.