Polling itu cara paling gampang bikin bot kerasa "hidup": cek terus, ada yang baru nggak, ada yang baru nggak. Jalan, sih. Tapi pas jumlah bot nambah dan API mulai ngitung tiap request, polling diam-diam jadi mahal. Ini cerita pindahnya, dan kapan polling sebenernya masih oke.
Polling = cek berulang di interval tetap, bayar request tiap siklus walau nggak ada yang berubah. Event-driven = cuma kerja pas ada event masuk (command, callback, webhook). Buat bot yang nungguin aksi user, event-driven jauh lebih hemat dan responsif. Tapi polling masih masuk akal buat hal yang emang nggak punya event push: harga on-chain, status tx, sumber data tanpa webhook. Kuncinya bukan "polling jelek" — tapi tau kapan dia rem yang salah.
Pola polling itu intuitif. Loop yang tiap sekian detik nanya ke API: "ada update?". Kalau ada, proses. Kalau nggak, tidur, ulang. Buat satu bot kecil, ini sempurna — gampang dipahami, gampang di-debug.
# Pola polling
while running:
updates = api.get_updates() # request tiap loop
for u in updates:
handle(u)
sleep(POLL_INTERVAL) # misal 5 detik
Masalahnya muncul pas di-scale. Interval 5 detik artinya 12 request per menit, 17.280 per hari — per bot. Dan mayoritas dari request itu balik kosong: nggak ada update, tapi tetap kebayar. Kali sepuluh bot, angka request yang kebuang jadi gede.
Ada tiga biaya yang nggak keliatan di awal:
Mayoritas poll balik tanpa data baru. Tiap request kosong tetap ngitung ke rate limit dan kuota API.
Update yang masuk pas abis poll harus nunggu sampai siklus berikutnya. Interval 5 detik = bot bisa telat 5 detik.
Kalau API mulai error, loop polling tetap hajar di interval yang sama. Tanpa backoff, ini malah mukulin API yang lagi sakit.
Biaya ketiga itu yang paling bahaya. Pernah gw nemu loop polling yang, pas API-nya error, malah nge-burn credit lebih cepat karena tiap error langsung di-retry tanpa jeda. Polling yang "diam-diam jalan" berubah jadi polling yang "diam-diam ngabisin kuota".
Pola event-driven balik logikanya. Bot nggak nanya terus "ada apa?". Dia diam, dan baru gerak pas ada event yang masuk — command dari user, klik tombol, atau webhook dari luar. Nol request pas nggak ada yang terjadi.
# Pola event-driven
app.add_handler(CommandHandler("check", do_check))
app.add_handler(CallbackQueryHandler(on_button))
# bot diam sampai ada event;
# nol request pas idle
app.run()
Buat bot yang nungguin aksi user — mayoritas Telegram bot gw — ini langsung nurunin request count drastis. Bot yang tadinya 17.280 poll per hari jadi cuma jalan pas user beneran ngetik command. Sisa waktu, dia diam, nol biaya.
Responsnya juga instan. Nggak ada latensi interval — event masuk, langsung diproses. Unified scraper gw sekarang full event-driven: nggak ada satu pun background polling loop, semua jalan dari handler.
Ini bagian yang sering kelewat. Event-driven menang buat hal yang punya event push. Tapi banyak sumber data nggak punya itu — harga token on-chain, status konfirmasi transaksi, API tanpa webhook. Buat itu, polling emang satu-satunya cara.
Bedanya, polling yang bener punya rem:
# Polling yang aman (buat sumber tanpa webhook)
while running:
try:
data = poll_source()
process(data)
backoff = BASE_INTERVAL # reset pas sukses
except Exception:
backoff = min(backoff * 2, MAX) # naikkan pas error
sleep(backoff)
Jadi keputusannya bukan "polling vs event-driven" sebagai benar-salah. Tanya satu hal: apakah sumbernya bisa ngasih tau gw pas ada perubahan? Kalau iya (user command, webhook), event-driven. Kalau nggak (harga, status on-chain), polling — tapi dengan backoff dan baseline, bukan loop telanjang.
Default ke event-driven buat apa pun yang nungguin user. Pakai polling cuma buat sumber yang nggak punya push, dan pas polling, selalu pasang backoff pas error plus baseline biar nggak banjir di run pertama. Polling tanpa rem itu sumber dari dua writeup gw yang lain di sini.