KAI Ticket Notifier — Monitor Ketersediaan Kereta Otomatis

Diagram arsitektur

Pilih simpul untuk membaca keputusan di baliknya

graph LR A[Konfigurasi monitor YAML] --> B[Scheduler Go] B --> C[Antrean browser bersama] C --> D[Chromium + SOCKS5] D --> E[BookingKAI resmi] C --> F[Filter ketersediaan] F --> G[Telegram Bot API] H[Cloudflare Tunnel] --> I[Webhook Telegram] I --> B click A call archNote() click B call archNote() click C call archNote() click D call archNote() click E call archNote() click F call archNote() click G call archNote() click H call archNote()

A Konfigurasi monitor YAML: YAML menjaga rute, tanggal, dan interval tetap bersifat operasional — menambah monitor tidak pernah butuh rebuild.
B Scheduler Go: Scheduler menyala dengan jeda bertingkat supaya beberapa tanggal tidak menghantam alur booking di momen yang sama.
C Antrean browser bersama: Satu antrean bersama menserialkan setiap pencarian lewat satu sesi Chromium persisten. Throughput turun, tapi monitornya bertahan berjalan tanpa dijaga — tukar-menukar itu disengaja.
D Chromium + SOCKS5: Dukungan proxy dikonfigurasi per provider, dan saat startup diverifikasi bahwa browser benar-benar keluar lewat IP yang berbeda sebelum pencarian apa pun dijalankan.
E BookingKAI resmi: Otomasi mengikuti alur web resmi, bukan endpoint privat yang tidak terdokumentasi. Tidak ada upaya melewati CAPTCHA atau tantangan interaktif — sistem malah mundur secara eksponensial.
F Filter ketersediaan: Hasil difilter berdasarkan kereta, rute, tanggal, harga, dan jendela keberangkatan sebelum ada yang dikirim. Hasil yang habis terjual dibiarkan diam.
G Telegram Bot API: Notifikasi digerakkan oleh ketersediaan, jadi chat hanya menerima pesan saat kursi benar-benar cocok.
H Cloudflare Tunnel: Mode webhook berjalan lewat Cloudflare Tunnel, jadi Telegram bisa menjangkau bot tanpa membuka port masuk.

Layanan otomasi praktis untuk masalah yang sederhana kalau cuma satu pencarian, tapi melelahkan kalau menyangkut beberapa tanggal perjalanan: terus mengecek hasil booking resmi KAI dan memberi tahu saya saat kereta yang tepat bisa dipesan.

Masalah

Ketersediaan bisa berubah di antara pengecekan. Membuka ulang halaman booking secara manual untuk beberapa tanggal menciptakan pekerjaan repetitif, dan monitor yang menjalankan banyak browser secara paralel bisa memicu rate limit atau mengacaukan sesi.

Solusi

Saya bangun layanan Go dengan monitor yang didefinisikan lewat YAML. Setiap jadwal menyerahkan pekerjaan ke antrean BookingKAI bersama, yang memakai ulang satu sesi Chromium dan memproses pencarian browser secara serial. Hasil yang cocok difilter berdasarkan kereta, rute, tanggal, harga, dan jendela keberangkatan sebelum Telegram diberi tahu.

Alur Pengguna

Definisikan kereta, rute, tanggal, interval, dan provider di YAML.
Layanan memvalidasi setiap kereta yang dikonfigurasi saat startup.
Scheduler menyerahkan pencarian ke antrean browser bersama dengan start bertingkat.
Chromium membuka alur booking resmi lewat proxy SOCKS5 opsional.
Hasil di-parse dan difilter; yang habis terjual dibiarkan diam.
Telegram menerima notifikasi saat ketersediaan yang cocok muncul.
Perintah bot bisa memeriksa, mengecek, menjeda, melanjutkan, atau menidurkan monitor untuk sementara.

Keputusan Arsitektur

Satu antrean browser bersama menserialkan request BookingKAI, mengurangi tekanan browser konkuren dan menjaga satu sesi persisten.
Scheduler menyala dengan jeda bertingkat supaya beberapa tanggal tidak menghantam alur booking bersamaan.
Otomasi browser dipakai untuk provider resmi karena alurnya bergantung pada sesi browser sungguhan; layanan tidak mencoba melewati CAPTCHA atau tantangan interaktif.
Dukungan proxy dikonfigurasi per provider, dan saat startup diverifikasi bahwa browser benar-benar keluar lewat IP yang berbeda.
YAML menjaga perubahan rute/tanggal tetap operasional, bukan menuntut rebuild.
Mode webhook memakai Cloudflare Tunnel, jadi Telegram bisa menjangkau bot tanpa membuka port server masuk.
Notifikasi digerakkan oleh ketersediaan; kegagalan karena tantangan memakai backoff, bukan membanjiri chat.

Pekerjaan Keandalan

Dukungan profil Chromium persisten untuk kesinambungan sesi
Validasi startup untuk setiap kereta yang dikonfigurasi
Backoff eksponensial saat BookingKAI menampilkan tantangan
Staggering scheduler yang rapi dan kepemilikan antrean bersama
Perintah Telegram untuk /list, /check, /status, /history, /toggle, dan /sleep berwaktu
Skrip setup Ubuntu yang mengecek dependensi dan membangun layanan secara reproducible

Trade-off

Otomasi browser lebih berat daripada API langsung, tapi ia mengikuti hasil web resmi dan menghindari ketergantungan pada endpoint privat yang tidak terdokumentasi.
Antrean serial menurunkan throughput, tapi keandalan lebih penting daripada kecepatan paralel untuk sekumpulan kecil monitor pribadi.
URL Cloudflare Tunnel cepat itu praktis untuk mode webhook, tapi deployment produksi yang stabil sebaiknya memakai named tunnel dan hostname persisten.

Yang Saya Pelajari

Bagian tersulit bukan menjadwalkan loop. Melainkan mengendalikan siklus hidup browser, konkurensi, backoff tantangan, verifikasi proxy, dan kebisingan notifikasi supaya monitor bisa terus berjalan tanpa dijaga.