Definisikan event

Pertanyaan

Apa tepatnya yang kita hitung, dan kapan sebuah event dianggap terjadi?

Setelah baca ini, kamu bisa menulis definisi event yang bisa dicek: kunci deduplikasi, jendela deduplikasi, waktu event versus waktu pemrosesan, dan aturan untuk event yang datang terlambat.

Prasyarat dan contoh

Kamu sudah paham partisi dan replikasi (M07) serta pengiriman at-least-once dan idempotensi (M10). Tanpa itu, bagian deduplikasi akan terasa seperti sulap.

Contoh: shortener internal tadi sekarang diminta menampilkan "jumlah klik" per tautan. Pertanyaan yang langsung muncul: klik dari bot dihitung? Orang yang me-refresh lima kali dihitung lima atau satu? Klik yang dikirim aplikasi mobile saat offline, lalu masuk tiga jam kemudian, dihitung di jam kapan?

Tiga orang bisa menjawab ketiganya berbeda, dan ketiganya konsisten dengan kata "klik". Itu sebabnya angka di dasbor dan angka di laporan bisa beda tanpa ada yang salah hitung.

Mekanisme

Tulis definisi event dalam lima bagian.

1. Apa yang dihitung. Pilih satu: event mentah (setiap request), event unik per kunci (setiap pasangan tautan dan pengunjung), atau event bersih (setelah bot disaring). Ketiganya angka yang sah, tapi tidak bisa saling menggantikan.

2. Kunci deduplikasi. Pengiriman at-least-once artinya event yang sama bisa masuk dua kali. Beri tiap event event_id yang dibuat produsen, bukan penerima. Kalau ID dibuat di server saat event diterima, retry dari klien jadi dua ID berbeda dan dedup tidak berguna.

3. Jendela deduplikasi. Menyimpan semua ID selamanya tidak realistis. Pilih jendela, misalnya 24 jam. Dengan 1.000 event per detik, itu 86,4 juta ID per hari. Dengan 16 byte per ID, sekitar 1,4 GB sebelum overhead struktur data, jadi muat di memori satu node atau beberapa node. Konsekuensinya jelas: duplikat yang datang lebih dari 24 jam kemudian akan terhitung dua kali. Tulis itu sebagai batas, bukan sebagai kejutan.

4. Dua jenis waktu. Waktu event adalah kapan hal itu terjadi di klien atau sumbernya. Waktu pemrosesan adalah kapan sistemmu melihatnya. Laporan "klik per jam" hampir selalu bermakna waktu event. Tapi waktu event datang dari perangkat yang jamnya bisa meleset, jadi tetapkan juga apa yang dilakukan dengan timestamp di masa depan atau terlalu jauh di masa lalu.

5. Event terlambat. Tentukan batas keterlambatan yang masih diterima (misalnya 6 jam) dan apa yang terjadi setelahnya: dibuang, ditulis ke tempat terpisah untuk koreksi manual, atau tetap memperbarui hasil lama.

Saat rancangan ini gagal

• Definisi berubah setelah data terkumpul. Produk minta "tanpa bot" bulan depan. Kalau yang tersimpan hanya counter, kamu tidak bisa menghitung ulang. Kalau event mentah masih ada, kamu tinggal menjalankan ulang dengan aturan baru.
• Dedup yang tidak sengaja bergantung pada waktu pemrosesan. Jendela 24 jam dihitung dari kapan event masuk, bukan dari waktu event. Event yang tertahan sehari di perangkat lolos dedup dan terhitung ganda.
• Jam perangkat salah. Ponsel dengan jam mundur tiga hari menaruh event di hari yang sudah ditutup. Tanpa aturan untuk itu, laporan harian yang sudah dikirim ke tim berubah diam-diam.
• Dua pembaca, dua definisi. Tim produk menghitung dari tabel mentah, tim keuangan dari agregat harian. Selisih 3% itu bukan bug. Itu dua definisi yang tidak pernah ditulis.

Latihan

Sebuah aplikasi mengirim event video_played. Klien mengirim ulang event kalau tidak menerima respons dalam 5 detik. Tim ingin angka "penonton unik per video per hari".

1. Apa yang dipakai sebagai kunci deduplikasi, dan siapa yang membuatnya?
2. Berapa jendela dedup yang masuk akal kalau klien offline paling lama 12 jam?
3. Apa yang terjadi pada event yang masuk 20 jam setelah waktu event?

Lihat pembahasan+

1. Pakai event_id (UUID) yang dibuat klien saat event terjadi, dan kunci unik penonton berupa (video_id, user_id, tanggal waktu event). Dua lapis: event_id membuang duplikat retry, kunci penonton membuat satu orang yang menonton tiga kali tetap terhitung satu.
2. Minimal 12 jam ditambah margin retry, jadi 24 jam adalah pilihan wajar. Untuk 500 event per detik, sekitar 43 juta ID per hari, kira-kira 0,7 GB pada 16 byte per ID. Muat di memori.
3. Event itu melewati batas keterlambatan 12 jam. Jangan dibuang diam-diam: tulis ke penyimpanan event terlambat, hitung jumlahnya sebagai metrik, dan putuskan apakah laporan harian dikoreksi atau tidak. Yang penting aturannya tertulis sebelum kasusnya terjadi.

Jawaban yang kuat menyebut batasnya sendiri: duplikat yang datang setelah 24 jam akan lolos.

Terkait

• Lanjut ke M12.02 Menghitung dalam kondisi berebut sumber daya.
• Soal event terlambat dan watermark dibahas lagi di M12.06 Kelola jendela waktu.
• Idempotensi dan pengiriman at-least-once dibahas di M10, yang belum tersedia.
• Rancangan D12 belum tersedia.

Catatan

• Asumsi: pengirim bisa membuat ID unik sendiri, dan ada penyimpanan event mentah.
• Yang nggak dibahas: deteksi bot, privasi pengguna, dan sinkronisasi jam perangkat.
• Angka ukuran ID adalah estimasi kasar tanpa overhead hash table atau replikasi.
• Terakhir ditinjau: 26 Oktober 2026.