Fan-out bukan kesalahan desain dengan sendirinya. Masalah muncul ketika satu request memicu terlalu banyak proses turunan sehingga membebani sistem secara tidak proporsional. Pada skala besar, fan-out yang tidak terkontrol dapat menjadi sumber utama ketidakstabilan.
Cara Fan-Out Terjadi
Fan-out biasanya muncul secara bertahap. Awalnya, sebuah layanan hanya memanggil satu dependensi. Seiring bertambahnya fitur, layanan tersebut mulai memanggil layanan lain, lalu dependensi tersebut melakukan hal yang sama.
Pada akhirnya, satu request pengguna bisa memicu puluhan atau ratusan operasi di belakang layar. Setiap operasi mungkin terlihat ringan, tetapi efek gabungannya sangat besar, terutama saat traffic meningkat.
Risiko Utama Fan-Out
Masalah fan-out bukan hanya soal beban, tetapi juga soal ketidakpastian perilaku sistem.
Beberapa risiko utama yang sering muncul:
1. Lonjakan beban mendadak, karena satu request kecil berubah menjadi banyak operasi paralel.
2. Latency yang membesar, karena waktu respon ditentukan oleh proses paling lambat di rantai pemanggilan.
3. Kegagalan berantai, ketika satu layanan lambat menyebabkan penumpukan request di banyak layanan lain.
4. Sulit diprediksi, karena biaya satu request tidak lagi konstan.
Risiko ini sering tidak terlihat saat beban rendah, tetapi muncul tiba-tiba saat sistem mendekati batas kapasitas.
Dampak pada Skalabilitas
Fan-out merusak asumsi dasar skalabilitas. Tim sering menghitung kapasitas berdasarkan jumlah request masuk, bukan jumlah operasi internal yang dihasilkan.
Akibatnya, sistem terlihat masih aman berdasarkan metrik traffic, padahal beban internal sudah mendekati titik jenuh. Ketika satu komponen melambat, seluruh rantai request ikut terpengaruh.
Fan-Out dan Observabilitas
Fan-out yang berlebihan sulit dianalisis tanpa observabilitas yang baik. Log dan metrik per layanan sering tidak cukup untuk memahami dampak satu request secara menyeluruh.
Tanpa pelacakan end-to-end, satu request bermasalah akan terlihat sebagai banyak masalah kecil yang tersebar. Ini membuat proses debugging lambat dan sering salah arah.
Strategi Pengendalian Fan-Out
Fan-out perlu dikelola secara sadar, bukan dibiarkan tumbuh alami.
Pendekatan yang umum digunakan antara lain:
1. Membatasi jumlah pemanggilan turunan dari satu request, terutama untuk operasi non-kritis.
2. Menggabungkan data di satu layanan agar tidak perlu memanggil banyak layanan lain.
3. Menggunakan cache untuk hasil yang sering dipakai ulang.
4. Memisahkan proses berat menjadi pemrosesan async agar tidak membebani request utama.
Pendekatan ini membantu menjaga biaya satu request tetap terkendali.
Kapan Fan-Out Bisa Diterima
Fan-out masih bisa diterima jika setiap pemanggilan memiliki biaya rendah dan batas yang jelas. Sistem internal dengan kontrol penuh dan latency stabil biasanya lebih aman dibanding dependensi eksternal.
Masalah muncul ketika fan-out tidak memiliki batas eksplisit dan bergantung pada kondisi runtime yang sulit diprediksi.
Satu Request Bukan Selalu Satu Biaya
Request fan-out risk mengajarkan bahwa satu request pengguna tidak selalu berarti satu beban sistem. Tanpa desain yang sadar fan-out, sistem bisa runtuh bukan karena traffic besar, tetapi karena struktur pemrosesan yang berlebihan.
Sistem yang sehat adalah sistem yang memahami dan membatasi konsekuensi dari setiap request, bukan hanya menghitung jumlah request itu sendiri.
Tidak ada komentar:
Posting Komentar