Mengingat semua hal yang harus disembunyikan oleh sistem terdistribusi dari penggunanya, ada satu aspek yang terkadang berada di luar kendali siapa pun: bagian dari sistem yang gagal. Bahkan dalam satu sistem, kegagalan adalah kemungkinan; dalam sistem terdistribusi, yang memiliki lebih banyak bagian yang bergerak yang bekerja bersama sekaligus, kegagalan adalah kenyataan.
Failure transparency atau Transparansi kegagalan memungkinkan pengguna akhir dari sistem terdistribusi untuk terus menggunakan sistem dan mengakses sumber daya apa pun tanpa menyadari bahwa bagian dari sistem telah gagal. Kegagalan dalam sistem terdistribusi juga disebut sebagai kesalahan sistem.
Karena kesalahan sistem hanyalah kenyataan, terserah pada kita, para perancang sistem terdistribusi, untuk mempertimbangkan apa kesalahan suatu sistem, dan bagaimana kita berencana untuk memulihkannya. Kadang-kadang sulit untuk mengidentifikasi semua kesalahan sistem, terutama karena sering kali tidak hanya mencakup kegagalan perangkat lunak, tetapi juga kegagalan perangkat keras!
Seringkali, memastikan transparansi kegagalan mungkin berarti memunculkan respons yang tertunda kepada pengguna sementara sistem menentukan apa sebenarnya kesalahannya, menemukan penyebabnya, dan menanganinya dengan cara yang diinginkan oleh pemrogram sistem. Namun, respons yang tertunda kepada pengguna akhir dapat membingungkan; misalnya, jika server gagal, dan pengguna tidak menyadari kesalahan dalam sistem, mungkin saja mereka berasumsi bahwa prosesnya tidak berhasil, daripada berpikir bahwa prosesnya hanya tertunda. Dalam beberapa kasus, transparansi replikasi dapat membantu langkah di sini, karena memiliki banyak salinan sumber daya berarti kita dapat memanfaatkan salinan lain jika salah satu akhirnya menjadi akar kegagalan.
Failure transparency ada di mana-mana yang mungkin kita sadari, dan banyak sistem terdistribusi yang kita gunakan setiap hari menjelaskan beberapa subset (potensial) kesalahan dalam sistem mereka. Misalnya, sistem manajemen basis data memiliki beberapa metode untuk memastikan transparansi kegagalan. Menangani transparansi kegagalan adalah salah satu aspek tersulit dalam merancang dan memelihara sistem terdistribusi.
Migrasi, replikasi, konkurensi, dan kegagalan: empat bentuk transparansi
Sekarang setelah kita membahas bentuk-bentuk utama transparansi, kita dapat mulai melihat bahwa beberapa bentuk transparansi tampaknya lebih mudah untuk dipertanggungjawabkan daripada yang lain. Bergantung pada ukuran dan skala sistem, bahkan mungkin mustahil untuk mencapai kegagalan yang sebenarnya atau transparansi konkurensi yang sebenarnya! Semua hal berbeda yang perlu kita “sembunyikan” dari pengguna akhir kita mungkin terasa sedikit berlebihan; bagaimana kita bisa menjelaskan semua ilusi ini saat merancang sistem terdistribusi?!
Pada kenyataannya, mencapai transparansi distribusi penuh dan berhasil memastikan akses, lokasi, relokasi, migrasi, replikasi, konkurensi, dan transparansi kegagalan dalam satu sistem terdistribusi adalah mustahil.
Memang ada batasan untuk apa yang kita, sebagai perancang sistem terdistribusi benar-benar dapat lakukan, dan apa yang benar-benar dapat kita pertanggungjawabkan! Dan terkadang, sebenarnya bukan demi kepentingan terbaik kami (atau bahkan demi kepentingan terbaik pengguna kami) untuk mempertahankan ilusi sistem kami. Transparansi adalah masalah yang sulit, dan kita tidak perlu menyalahkan diri sendiri jika kita tidak bisa sepenuhnya transparan (karena pada kenyataannya kita bahkan tidak bisa melakukannya).