Ketika pulang kerja di salah satu Halte

Ketika pulang kerja di salah satu halte, jam 8 malam saya baru saja membeli roti untuk dimakan di perjalanan. Saat hendak membayar, proses transaksi melalui bank pertama tiba-tiba macet tepat ketika bus datang. Karena saya mengira pembayarannya gagal, saya langsung mengganti pembayaran ke bank lain dan transaksi berjalan lancar. Saya pun naik bus tanpa menyangka bahwa transaksi pertama sebenarnya tetap terproses.

Namun setelah berada di dalam bus, saya baru menyadari bahwa transaksi melalui bank pertama ternyata tetap terpotong. Artinya, saya akhirnya membayar dua kali untuk satu roti karena transaksi pertama yang macet tadi tetap masuk. Tentu saja saya kesal. Saya langsung diminta menghubungi layanan pelanggan perbankan melalui telepon, yang ironisnya berbayar pulsa dan harus antre pula. Rasanya absurd: untuk memperbaiki kesalahan sistem, saya harus mengeluarkan biaya tambahan sebesar harga roti yang sama.

Sebagai seorang backend engineer, pengalaman ini membuat saya benar-benar merasakan bagaimana ruginya seorang pelanggan ketika terjadi masalah seperti ini. Setiap detik delay, setiap proses yang stuck, dan setiap transaksi yang tidak memberikan kepastian langsung berdampak pada frustrasi pelanggan. Mengalami sendiri situasi tersebut membuat empati saya meningkat; saya jadi semakin sadar bahwa apa yang kami bangun di backend memiliki konsekuensi nyata bagi pengguna di lapangan.

Disini Mindset itu berubah

Di sini mindset saya berubah. Banyak orang berpikir bahwa frontend adalah bagian yang menentukan kesabaran pelanggan, tetapi kenyataannya tidak sesederhana itu. Fondasi pengalaman pengguna justru ditentukan oleh bagaimana backend memproses permintaan, mulai dari latensi, stabilitas, reliabilitas, hingga konsistensi data. Ketika backend lambat merespons atau gagal memberikan status final tepat waktu, pelanggan akan merasa UI sebagus apa pun tidak ada artinya.

Masalah seperti transaksi yang dianggap gagal tetapi tetap terpotong biasanya muncul karena latensi di berbagai titik backend. Mulai dari komunikasi antar microservice yang memakan waktu, lambatnya API bank pihak ketiga, retry yang tidak dilindungi idempotency key, sampai database yang terlambat menulis status. Semua faktor ini tidak terlihat oleh pelanggan. Bagi mereka, yang penting hanya dua hal: apakah berhasil dan seberapa cepat.

Upaya menurunkan latensi harus dilakukan menyeluruh dari kode sampai infrastruktur. Di sisi kode, kita perlu mengurangi operasi blocking, menyederhanakan jalur kritis, meminimalkan logging yang berat, dan memanfaatkan asynchronous processing. Di tingkat arsitektur, kita bisa mengurangi jumlah hop antar service, menambah caching, menggunakan connection pooling, dan menerapkan idempotency dengan benar. Observability seperti tracing p95 dan p99 juga penting untuk menemukan bottleneck tersembunyi.

Di infrastruktur, langkah yang paling penting adalah memisahkan payment service sebagai layanan khusus yang memiliki CPU dan memori tersendiri. Jalur pembayaran adalah bagian yang paling sensitif, sehingga tidak boleh berbagi resource dengan layanan lain seperti notifikasi atau rekomendasi. Dengan punya lingkungan tersendiri, performanya tidak akan terpengaruh oleh lonjakan beban di bagian lain. Konfigurasi seperti instance premium, autoscaling cepat, prioritas lebih tinggi, dan jaringan yang stabil bisa diterapkan khusus untuk pembayaran. Dengan cara ini, transaksi bisa tetap cepat, konsisten, dan tepercaya.

Kesimpulan

Semuanya kembali pada kepuasan pelanggan. Mereka tidak peduli seberapa rumit arsitektur backend yang kita bangun. Yang mereka ingin rasakan hanyalah transaksi yang cepat, berhasil, dan tidak menimbulkan kerugian. Microservices memang baik karena memisahkan tanggung jawab di level infrastruktur. Namun jika sistem masih monolitik atau setengah monolitik, peningkatan masih tetap bisa dilakukan. Bagian yang mengurus pembayaran bisa dipisahkan atau diduplikasi menjadi deployment sendiri. Endpoint penting seperti pembayaran bisa diarahkan ke layanan baru melalui API gateway atau nginx proxy. Cara ini meningkatkan performa jalur pembayaran tanpa migrasi besar, tetapi tetap menjaga pengalaman pelanggan tetap aman dan nyaman.