Di Plasma, aplikasi dibuat terutama di sekitar skenario frekuensi tinggi seperti transfer, penerimaan, penyelesaian, dan tabungan stablecoin. Banyak pengembang yang paling mudah salah menilai satu hal: selama rantai dapat berjalan dan transaksi dapat dikirim, itu dianggap "diluncurkan". Namun, skenario pembayaran benar-benar menguji stabilitas jangka panjang—bukan "apakah bisa berhasil sekali", tetapi "apakah masih dapat diprediksi saat puncak, goyangan, atau kerusakan". Ini mengharuskan Anda untuk menganggap keandalan sebagai bagian dari produk: pemantauan bukanlah lampiran operasional, peringatan bukan hanya dilihat saat ada masalah, dan rencana pemulihan juga bukan hanya ditulis dalam dokumen. Anda perlu mengembangkan sistem ini menjadi jaring, yang tidak terlihat di waktu biasa, tetapi dapat menampung pengalaman pada saat-saat kritis.
Prinsip pertama pemantauan: jangan hanya fokus pada TPS, tetapi fokus pada "pengalaman buruk yang dapat dirasakan pengguna".
Indikator inti dari aplikasi tingkat pembayaran bukanlah "throughput", tetapi "kegagalan dan penundaan". Anda perlu memantau tiga jenis indikator pengalaman dalam jangka panjang: rasio keberhasilan pengajuan transaksi, distribusi waktu konfirmasi akhir transaksi (terutama P95/P99), serta proporsi ketidakcocokan status di dalam dan luar rantai. Banyak insiden bukan karena rantai berhenti, tetapi melambat, menjadi tidak stabil, atau gagal sesekali; jika tidak ada pemantauan kuantil, Anda akan melihat "rata-rata normal" di grafik, tetapi pengguna sudah mengeluh "kenapa selalu tidak ada uang yang masuk".
Peringatan harus dimulai dari "anomaly" dan bukan "nilai absolut", jika tidak, Anda akan tenggelam dalam kebisingan.
Sistem pembayaran paling takut pada kelelahan alarm. Anda tidak bisa hanya menetapkan satu "rasio kegagalan > 1% untuk memberi alarm", karena kebisingan dari periode waktu yang berbeda, daerah yang berbeda, dan penyedia RPC yang berbeda akan membuat Anda terus berdering. Cara yang lebih praktis adalah membangun baseline: ketika rasio kegagalan, penundaan konfirmasi, dan rasio timeout RPC tiba-tiba menyimpang dari rentang normal 1-3 jam atau 24 jam terakhir, baru kemudian memicu alarm, sambil menggabungkan kondisi "keterusan" (misalnya alarm hanya setelah 5-10 menit berkelanjutan). Dengan cara ini, yang Anda tangkap bukanlah getaran acak, tetapi tren yang benar-benar bisa menyebar menjadi insiden.
Anda harus memperlakukan RPC sebagai sistem multi-hidup: rantai tidak ada masalah, RPC juga bisa membuat Anda "terlihat seperti offline".
Menjalankan aplikasi pembayaran di Plasma, salah satu sumber insiden yang paling umum adalah di sisi RPC: node tertinggal, pengendalian, timeout, hasil yang tidak konsisten, mempool tidak sinkron. Anda harus memperlakukan penyedia RPC sebagai kluster multi-hidup untuk dikelola: melakukan pemeriksaan kesehatan untuk setiap penyedia (penundaan, rasio kesalahan, keterlambatan tinggi blok), dan memisahkan rute baca dan tulis; transaksi tulis harus melalui saluran yang lebih stabil dan dapat dikontrol, status baca harus dapat beralih dan menurun secara otomatis. Bagi pengguna, mereka tidak peduli masalahnya ada di rantai atau di RPC, mereka hanya peduli "apakah uang saya sudah sampai atau belum", jadi Anda harus membuat "kemampuan melihat rantai" juga dapat diandalkan.
Rencana rollback bukan "rollback transaksi", tetapi "rollback pengalaman": mesin status di luar rantai harus dapat menyembuhkan diri sendiri.
Transaksi di rantai sekali terjadi tidak dapat dibatalkan, aplikasi pembayaran dapat melakukan rollback, biasanya adalah status di luar rantai: pesanan, tampilan saldo, pemberitahuan, pengurangan kuota, distribusi poin. Anda harus merancang proses yang dapat dikompensasi: beku dulu, lalu selesaikan, konfirmasi setelahnya, jika gagal, maka dibekukan kembali; ketika terjadi timeout atau status tidak pasti, jangan biarkan pengguna mengirimkan ulang, tetapi gunakan request_id untuk melacak keunikan tindakan yang sama, periksa terlebih dahulu apakah sudah ada di rantai, baru putuskan untuk melanjutkan menunggu atau memulai kompensasi. Tujuan sebenarnya dari rencana rollback adalah agar pengguna merasakan bahwa "sistem sedang memproses", dan bukan membuatnya panik dan terus mengklik yang dapat menyebabkan transaksi ulang yang lebih buruk.
Sebuah strategi darurat yang matang: penurunan tingkat, dan bukan penghentian keras.
Keandalan sistem pembayaran sering kali berasal dari "penurunan yang dapat dikontrol". Ketika Anda mendeteksi gangguan jaringan atau ketidakstabilan node, Anda bisa sementara menutup fungsi yang tidak penting (seperti Vault strategi kompleks, penyegaran sering, beberapa kueri biaya tinggi), memprioritaskan transfer dan penerimaan kupon sebagai jalur inti; ketika risiko transaksi meningkat, bisa menurunkan batas pembayaran, meningkatkan ambang batas kontrol risiko, memperketat ruang daftar putih, memastikan sistem tidak akan tertekan oleh volume yang berlebihan atau kemacetan. Dengan cara ini, meskipun ada masalah, Anda tetap bisa membuat pengguna menyelesaikan tindakan yang paling penting, bukan seluruh sistem yang runtuh.
Kesimpulan inti dari B11 adalah: dalam membuat aplikasi tingkat pembayaran di Plasma, Anda harus menjadikan keandalan sebagai kemampuan produk—menggunakan pemantauan untuk mendeteksi tren sebelumnya, menggunakan alarm untuk menentukan lokasi kegagalan dengan tepat, menggunakan RPC multi-hidup untuk menjamin observabilitas dan ketersediaan, serta menggunakan mesin status yang dapat dikompensasi dan tingkat penurunan untuk menjaga pengalaman pengguna. Setelah sistem ini berjalan, keuntungan "jaringan penyelesaian" Plasma dapat benar-benar diterapkan pada produk Anda, dan bukan hanya tertulis dalam narasi.