Platform Telemetri Frontend Real-Time

Masalahnya

Sebagian pengguna diam-diam berhenti di tengah alur panjang yang terdiri dari banyak langkah. Ketika integrasi dengan pihak ketiga rusak, tidak ada yang melihatnya: diagnosis berarti membaca log server yang terpecah-pecah secara manual dan memakan waktu berhari-hari. Setiap hari itu adalah pengguna nyata yang tidak bisa menyelesaikan prosesnya.

Pendekatannya

• SDK kecil yang bertipe. Satu tracker TypeScript mengumpulkan data aksi pengguna yang sama di setiap layar dan platform, sehingga sebuah event bermakna sama di mana pun.
• Throttling dengan katup pengaman. SDK mengelompokkan event dan mengirimnya saat timer singkat atau batas ukuran tercapai, mana pun yang lebih dulu. Satu request per klik membuat thread jaringan browser kehabisan jatah; menahan event lebih lama berisiko kehilangannya saat tab ditutup, jadi saat halaman ditutup dipakai navigator.sendBeacon.
• BFF yang memvalidasi. Batch event masuk ke Backend for Frontend yang memeriksa skema terhadap definisi TypeScript, memeriksa kewajaran timestamp, membuang field tak terduga dan data pribadi, lalu menambahkan metadata sesi. Membandingkan keputusan backend dengan apa yang ditampilkan UI mengungkap ketidaksesuaian state di antara keduanya.
• Pipeline streaming ke penyimpanan kolumnar. Streaming menyerap lonjakan trafik, dan penyimpanan kolumnar menjawab agregasi atas kumpulan event yang sangat besar dan berkardinalitas tinggi dalam hitungan milidetik, di mana penyimpanan berbasis baris merangkak.
• Penanganan kegagalan yang senyap. Jika pipeline mati, SDK menyimpan buffer kecil secara lokal dan circuit breaker pasif menghentikan pengiriman. SDK tidak melakukan ping ke server untuk mengecek kesehatannya; ia menunggu respons sukses berikutnya.

Hasilnya

Waktu deteksi insiden turun dari hitungan hari menjadi di bawah 5 menit. Ketika satu langkah yang rusak berarti banyak percobaan gagal, itulah beda antara catatan di postmortem dan perbaikan di pagi yang sama.