Seorang mantan insinyur infrastruktur Reddit baru-baru ini membagikan pendekatan mereka untuk menyelesaikan masalah distributed queue yang melanda platform media sosial tersebut lebih dari satu dekade lalu. Artikel tersebut menjanjikan wawasan tentang bagaimana mereka mengatasi masalah di mana vote pengguna, komentar, dan submission bisa menghilang ketika sistem mengalami kegagalan. Namun, komunitas teknis telah mengajukan pertanyaan tentang kelengkapan penjelasan dan pembingkaian solusi tersebut.
Masalah Asli di Reddit
Selama tahun-tahun awal Reddit , platform tersebut sangat bergantung pada RabbitMQ sebagai message broker mereka untuk menangani interaksi pengguna. Ketika pengguna melakukan upvote pada postingan, tindakan tersebut masuk ke dalam distributed queue sebelum mencapai database. Arsitektur ini menyediakan horizontal scaling dan flow control tetapi datang dengan masalah reliabilitas yang signifikan. System crash bisa mengakibatkan hilangnya data, dan ketika queue itu sendiri mengalami gangguan, vote pengguna dan komentar akan hilang begitu saja.
Insinyur tersebut menjelaskan bahwa yang benar-benar dibutuhkan Reddit adalah durable queue yang melakukan checkpoint status tugas ke penyimpanan persisten seperti PostgreSQL . Sistem ini menggabungkan task queue dengan durable workflow, memungkinkan job yang gagal untuk melanjutkan dari langkah terakhir yang diselesaikan daripada memulai dari awal atau menghilang sepenuhnya.
Arsitektur Asli Reddit (15+ tahun yang lalu):
- Message Broker: RabbitMQ
- Cache: Sistem seperti Redis
- Database: PostgreSQL
- Alur: Aksi pengguna → Queue + Cache → Respons sukses → Processor queue → Database + Penghitungan ulang
Pertanyaan Komunitas Tentang Kesenjangan Teknis
Komunitas teknis telah menunjukkan beberapa masalah dengan presentasi artikel tersebut. Kritikus mencatat bahwa artikel tersebut tidak pernah secara eksplisit menjelaskan bagaimana penulis menyelesaikan masalah asli, meskipun judulnya menjanjikan. Artikel tersebut fokus berat pada mendeskripsikan durable queue sebagai konsep tetapi kurang spesifik tentang implementasi atau perbandingan dengan solusi yang ada.
Apakah saya melewatkan sesuatu atau artikel tersebut tidak pernah membahas judulnya? Postingan ini adalah deskripsi yang bagus tentang durable queue, tetapi tidak pernah secara eksplisit mengatakan bahwa mereka adalah solusi untuk masalah distributed queue, juga tidak secara spesifik mendefinisikan masalah tersebut.
Selain itu, developer berpengalaman telah mempertanyakan apakah RabbitMQ itu sendiri yang menjadi masalah, mencatat bahwa bahkan 15 tahun lalu, RabbitMQ mendukung durability dan transaksi dengan kemampuan rollback. Beberapa menyarankan bahwa masalah yang dijelaskan mungkin berasal dari penggunaan RabbitMQ yang salah daripada keterbatasan teknologi itu sendiri.
 |
|---|
| Kemacetan lalu lintas melambangkan kongesti dan inefisiensi yang terlihat dalam manajemen antrian terdistribusi, mencerminkan kekhawatiran komunitas terhadap solusi artikel asli |
Diskusi Durable Workflow
Fokus artikel bergeser secara signifikan ke arah durable workflow, yang berbeda dari simple durable queue. Durable workflow memungkinkan developer untuk menulis kode yang dapat berhenti dan melanjutkan eksekusi melintasi kegagalan sistem, mempertahankan state dalam penyimpanan persisten. Teknologi ini telah mendapat daya tarik dengan platform seperti Temporal , DBOS , Inngest , dan Restate yang menawarkan berbagai implementasi.
Namun, anggota komunitas mencatat bahwa durable workflow mengharuskan developer untuk merestrukturisasi kode mereka di sekitar custom async runtime dan callback-style programming. Ini merepresentasikan perubahan arsitektural yang signifikan yang melampaui sekadar membuat queue lebih reliabel.
Catatan: Durable workflow adalah sistem yang dapat menghentikan dan melanjutkan proses yang berjalan lama melintasi kegagalan sistem dengan menyimpan state mereka ke penyimpanan persisten pada checkpoint kunci.
Platform Durable Queue yang Disebutkan:
- Temporal (https://temporal.io/)
- DBOS (https://www.dbos.dev/)
- Inngest (https://www.inngest.com/)
- Restate (https://restate.dev/)
 |
|---|
| Potongan kode Python menunjukkan bagaimana antrian tahan lama dapat diimplementasikan, mewakili bagian vital dari restrukturisasi alur kerja seperti yang dibahas dalam artikel |
Trade-off Performa dan Alternatif Modern
Diskusi mengungkapkan pertimbangan penting tentang kapan memilih durable queue dibandingkan solusi tradisional. Durable queue biasanya menggunakan relational database seperti PostgreSQL untuk message brokering dan storage, yang memberikan jaminan yang lebih kuat tetapi berpotensi throughput yang lebih rendah dibandingkan dengan solusi in-memory seperti Redis .
Komunitas juga mengajukan pertanyaan tentang bagaimana pendekatan ini dibandingkan dengan platform streaming modern seperti Kafka , yang dapat memberikan durability dan performa tinggi. Beberapa berargumen bahwa pilihan antara teknologi queuing yang berbeda lebih bergantung pada kasus penggunaan spesifik dan detail implementasi daripada keterbatasan arsitektural fundamental.
Trade-off Teknis Utama:
- Queue Tradisional: Throughput lebih tinggi, penyimpanan dalam memori ( Redis ), potensi kehilangan data
- Queue Tahan Lama: Throughput lebih rendah, penyimpanan persisten ( PostgreSQL ), jaminan durabilitas
- Performa: Queue tahan lama lebih baik untuk tugas volume rendah yang kritis untuk bisnis; queue tradisional lebih baik untuk tugas volume tinggi yang lebih kecil
Kesimpulan
Meskipun artikel asli bertujuan untuk berbagi pelajaran yang dipetik dari menyelesaikan masalah distributed queue di Reddit , artikel tersebut justru memicu diskusi yang lebih luas tentang evolusi teknologi message queuing dan trade-off yang terlibat dalam pendekatan yang berbeda. Respons komunitas menyoroti pentingnya memberikan detail teknis yang konkret dan mengakui lanskap penuh solusi yang tersedia ketika membahas tantangan infrastruktur. Percakapan terus berkembang di sekitar praktik terbaik untuk membangun sistem terdistribusi yang reliabel dalam aplikasi modern.
Referensi: How I solved a distributed queue problem after 15 years