14 September
Kami sudah menunggu-nunggu hari ini selama berminggu-minggu. Penyedia proxy residensial kami sempat mati total karena gagal bayar sejak Juli, dan selama dua bulan porsi yang terus membesar dari 1.375 sumber kami melakukan crawl secara terdegradasi atau bahkan tidak sama sekali — fetch yang timeout, IP yang diblokir di tengah sesi, jenis pendarahan lambat yang tidak muncul sebagai gangguan besar melainkan sebagai angka yang terus menyusut tanpa disadari siapa pun sampai akhirnya memalukan. Kami pun memperbarui kontrak. Pool baru, 20.000 baris sesi residensial rotating, setiap exit diperiksa sebelum dibiarkan mendekati production. 100% dari pemeriksaan lolos. AE, DE, JP — semuanya aktif, semuanya bersih.
Jadi kami menjalankan crawl yang diawasi langsung, jenis crawl di mana ada orang yang benar-benar memantau dashboard alih-alih mempercayakannya pada cron. Saya menduga hasilnya akan berkebalikan dari bencana.
Yang kami dapatkan justru database yang kehilangan 84.401 baris dalam satu kali jalan, dengan 102 sumber turun lebih dari 25% dibandingkan snapshot sebelumnya. Lebih buruk daripada dua bulan kelaparan proxy yang baru kami perbaiki.
Teori yang salah, secara singkat
Dugaan pertama saya — dan saya akui ini terang-terangan — adalah bahwa pool baru ini entah bagaimana lebih buruk daripada yang ditunjukkan hasil pemeriksaan. Mungkin IP sesi kena rate-limit di tengah crawl, dengan cara yang tidak akan tertangkap oleh pemeriksaan sekali tembak. Ini teori yang masuk akal. Tapi juga salah, dan mempercayainya bahkan hanya setengah hari saja menghabiskan waktu yang sebenarnya tidak kami miliki, karena cron crawl tetap dijeda selama kita masih men-debug teori semacam itu — kita tidak mau satu kali jalan yang buruk menimpa snapshot yang baik selagi kita masih menduga-duga.
Tanda yang akhirnya membongkar teori itu adalah dubizzle. Salah satu sumber volume tertinggi kami di UAE, yang justru berhasil mengambil 32.595 listing selama crawl itu — angka yang sangat sehat, proxy jelas berfungsi — dan kemudian membuang hampir semuanya. Bukan gagal mengambil. Berhasil mengambil, lalu dibuang.
16 September: menemukan bug yang sebenarnya
Di titik itulah ceritanya berhenti menjadi soal proxy dan berubah menjadi soal penggantian baris data. Lapisan persistence kami melakukan snapshot setiap sumber sebagai overwrite penuh terhadap <site>_cars_for_sale.csv setiap kali jalan — hanya listing aktif saat ini, mengganti seluruh tabel. Itu perilaku yang benar ketika sebuah crawl selesai sepenuhnya. Tapi jadi bencana ketika sebuah crawl timeout di tengah jalan dan scraper menulis batch parsial apa pun yang berhasil dikumpulkannya seolah-olah itu adalah snapshot lengkap. Sumber yang biasanya menyimpan 9.000 listing aktif malah ditimpa dengan 1.200 yang berhasil di-scrape sebelum waktu habis, dan 7.800 sisanya lenyap — bukan karena mobilnya terjual, tapi karena kode kami sendiri yang memutuskan bahwa fetch yang belum selesai adalah fetch yang lengkap.
Proxy-nya tidak berbohong pada kami. Logika retry-nya yang jadi masalah, dan itu sudah lama diam-diam buruk, hanya saja selama ini tertutupi oleh pool yang lebih sehat yang biasanya menyelesaikan fetch sebelum sweep itu jadi masalah.
Begini biaya sebenarnya dari sweep itu, setelah kami hitung-hitung:
| Sweep retry lama | Sweep yang sudah diperbaiki | |
|---|---|---|
| Retry per proxy | 3 | 1 |
| Delay per percobaan | 1s | — |
| Batas efektif di satu pool 50-proxy | ~56 menit per URL | Total budget 120 detik |
| Perilaku saat timeout | menulis batch parsial sebagai snapshot lengkap | sumber dilewati, snapshot sebelumnya dipertahankan |
Lima puluh enam menit hanya untuk menyerah pada satu URL saja. Kalikan itu dengan crawl yang menyentuh lebih dari seribu sumber, dan hasilnya tepat seperti yang kami lihat: kegagalan yang senyap dan tersebar tidak merata — sebagian sumber baik-baik saja, 102 lainnya hancur, tanpa ada yang berteriak "proxy mati" di log, karena, secara teknis, memang tidak ada yang mati.
25 September: perbaikannya, dan bagian yang penting bagi Anda
Patch yang dirilis sembilan hari kemudian melakukan dua hal yang tidak terlalu mentereng. Pertama, membatasi perhitungan retry sehingga fetch yang macet gagal dengan cepat alih-alih menghabiskan hampir satu jam. Dan — ini yang benar-benar mencegah kehilangan data — fetch parsial tidak lagi menggantikan keseluruhan baris data. Jika sebuah sumber hanya berhasil mengambil 1.200 dari biasanya 9.000 listing, kami mempertahankan snapshot lengkap sebelumnya alih-alih menimpanya dengan sebagian kecil itu. Di hari yang sama, perubahan kedua dirilis yang menulis flag CRAWL_PAUSED yang terlihat, yang diperiksa sistem monitoring kami sebelum mengirim peringatan ke siapa pun soal penurunan data — jadi jeda yang disengaja terbaca sebagai jeda, bukan sebagai alarm.
Mengapa pembaca yang sedang mencari Hyundai bekas harus peduli dengan semua ini? Karena tanda di bawah harga pasar yang kami terbitkan — 12.823 tanda aktif di situs per minggu ini — hanya jujur jika kohort yang kami bandingkan dengan sebuah listing adalah pasar regional yang nyata dan lengkap, bukan fragmen yang terpotong akibat timeout. Lencana "deal" yang dibangun dari snapshot yang kehilangan tiga perempat set pembandingnya bukan lagi lencana deal, melainkan noise berlabel hijau. Kami lebih memilih menjeda crawl selama sembilan hari daripada menerbitkan itu.
Dataset hari ini berisi 1.108.535 listing di 73 region dan 1.375 sumber — lebih besar daripada sebelum semua ini bermula, dengan proxy yang sudah diperbarui dan bug penggantian baris yang sudah ditutup. Tapi angka yang terus saya ingat bukan totalnya. Melainkan 84.401 — selisih antara crawl yang terlihat sehat di lapisan proxy dan crawl yang benar-benar sehat.
