Insinyur mendapat panduan lapangan untuk sistem fintech

Buku Panduan Rekayasa Fintech memaparkan serangkaian pola praktis bagi para insinyur yang membangun perangkat lunak di sekitar uang, mulai dari desain buku besar dan idempotensi hingga webhook, rekonsiliasi, kontrol akses, dan pengujian di produksi.

Buku panduan ini ditujukan bagi insinyur yang masuk ke fintech dari bidang perangkat lunak lain. Aplikasi sosial bisa pulih dari notifikasi duplikat. Sistem uang tidak bisa mengabaikan penarikan duplikat, biaya yang dibulatkan habis, atau catatan penyelesaian yang hilang. Panduan ini membingkai pekerjaan itu di sekitar tiga aturan: jangan mengarang data, jangan kehilangan data, dan jangan mempercayai sistem eksternal atau internal tanpa pemeriksaan.

Pelajaran pertama dimulai dari representasi. Uang membutuhkan jumlah dan mata uang, disimpan dengan presisi yang cukup untuk tugasnya. Buku panduan ini memperingatkan agar tidak memakai tipe floating-point untuk nominal keuangan karena parser dan runtime yang umum dapat memperkenalkan kesalahan pembulatan di tepi sistem yang sebetulnya sudah hati-hati. Buku ini mengarahkan tim ke unit minor tetap, desimal presisi arbitrer, bilangan rasional, atau kombinasi pendekatan tersebut, tergantung apakah sistem menyimpan saldo, menghitung kurs, atau menangani aset kripto.

Perbedaan itu penting. Saldo fiat $12,34 mungkin cocok disimpan sebagai 1.234 sen di bawah metadata mata uang dalam ISO 4217. Sebuah token kripto mungkin memakai 18 desimal dan melampaui integer 64-bit. Sebuah angka JSON mentah dapat merusak desain internal yang hati-hati jika klien mem-parse-nya sebagai double IEEE 754. Buku panduan ini mendorong insinyur untuk mengirim uang sebagai string atau integer satuan terkecil sebagai gantinya.

Panduan ini memperlakukan pembulatan sebagai keputusan bisnis, bukan persoalan pemformatan. Perhitungan biaya, konversi mata uang, bunga, dan penerapan kurs semuanya dapat menciptakan pecahan yang harus dialokasikan oleh sistem. Tim perlu memilih siapa yang menerima atau kehilangan sisa pembulatan, mencatat residunya, dan menghindari pembulatan sampai batas seperti penyimpanan atau tampilan. Jika sebuah platform membagi satu pembayaran menjadi beberapa bagian, bagian yang sudah dibulatkan mungkin tidak lagi menjumlah kembali ke jumlah awal. Buku panduan ini mendesak tim untuk melacak selisih itu alih-alih menyembunyikannya.

Bagian buku besar memberi buku panduan ini pusat gravitasinya. Panduan ini menjelaskan pembukuan entri ganda sebagai pola rekayasa: setiap perpindahan mengkredit satu akun dan mendebit akun lain, sehingga uang memiliki sumber dan tujuan. Penyedia eksternal juga mendapat akun. Saldo pengguna berasal dari posting, bukan dari field saldo yang dapat diubah. Koreksi terjadi melalui entri baru yang tertaut, bukan dengan mengedit catatan yang sudah diposting.

Pendekatan itu memberi auditor jejak. Sistem keuangan perlu menjelaskan apa yang terjadi, siapa yang memicu, kapan sistem membukukan, mengapa itu terjadi, dan data sumber mana yang mendukung keputusan tersebut. Buku panduan ini memisahkan waktu nilai, waktu pembukuan, dan waktu penyelesaian karena tanggal-tanggal itu menjawab pertanyaan yang berbeda. Transaksi kartu mungkin terjadi pada hari Senin, masuk ke sistem perusahaan pada hari Selasa, dan selesai ke bank pada hari Jumat. Menyatukan tanggal-tanggal itu ke dalam satu field created_at menghilangkan fakta yang tidak bisa direkonstruksi lagi oleh tim di kemudian hari.

Buku panduan ini juga memperlakukan event sourcing dengan hati-hati. Event sourcing dapat memberi tim jejak audit yang kuat karena log event menjadi sumber untuk state turunan. Panduan ini tidak menjualnya sebagai jawaban universal. Insinyur tetap memerlukan proyeksi, snapshot, evolusi skema, dan alat untuk event lama yang harus bertahan selama bertahun-tahun. Untuk banyak domain di sekitarnya, buku panduan ini mengatakan bahwa model konvensional dengan log perubahan yang andal dapat memenuhi kebutuhan dengan biaya operasional yang lebih rendah.

Pola eksekusi mengambil bagian besar lain dari panduan ini. Idempotensi mendapat perhatian khusus karena sistem fintech melakukan retry dengan sengaja. Sebuah permintaan penarikan dapat timeout setelah penyedia menerimanya. Klien mungkin mencoba lagi. Server harus menggabungkan pengiriman itu menjadi satu efek. Buku panduan ini mendukung idempotency key yang eksplisit, dicakup ke klien dan operasi, ditambah penghalang atomik yang menangani dua permintaan duplikat yang tiba pada saat yang sama.

Reservasi dana menangani race yang berbeda. Sebelum sebuah platform mengirim uang keluar atau memanggil penyedia kepatuhan, platform tersebut mereservasi jumlah yang diperlukan terhadap saldo tersedia pengguna. Pengguna masih memiliki dana itu, tetapi sistem mencegah transaksi lain membelanjakan jumlah yang sama. Panduan ini menegaskan satu syarat keras: memeriksa saldo dan mencatat reservasi memerlukan konsistensi kuat. Pembacaan yang usang dapat membiarkan dua penarikan lolos terhadap dana yang sama.

Buku panduan ini tidak berpura-pura bahwa reservasi menghilangkan saldo negatif. Sistem eksternal dapat memaksa saldo menjadi negatif melalui penyelesaian yang lebih tinggi dari perkiraan, pembalikan, chargeback, atau biaya yang tertunda. Panduan ini memperingatkan insinyur agar tidak mengkodekan saldo nonnegatif sebagai tipe unsigned atau constraint basis data yang menolak kenyataan. Sistem yang tidak bisa merepresentasikan saldo negatif dapat crash, menjepit nilainya ke nol, atau mencetak uang melalui jalur perbaikan yang buruk. Buku panduan ini menyuruh tim membukukan overdraft, menyelidikinya, dan memulihkannya melalui setoran mendatang, pelunasan, atau akun kerugian.

Integrasi eksternal menerima ketidakpercayaan yang sama. Pemroses pembayaran, bank, kustodian, vendor KYC, vendor AML, node blockchain, dan layanan internal dapat mengembalikan payload yang rusak, catatan usang, pesan duplikat, atau keheningan. Buku panduan ini menyarankan tim untuk memvalidasi field yang mereka andalkan, menyimpan request dan respons dalam bentuk yang bisa di-query, dan melakukan perhitungan kasar terhadap kuota penyedia sebelum traffic menyingkap batas.

Webhook mendapat perlakuan yang tegas. Sebuah webhook seharusnya memicu pemeriksaan, bukan menetapkan suatu fakta. Panduan ini merekomendasikan verifikasi signature atas byte mentah, menyimpan payload mentah, memberi acknowledgment dengan cepat, dan memproses pekerjaan di luar jalur request. Tim harus menanyakan API penyedia untuk status terkini dan membangun job rekonsiliasi untuk webhook yang tidak pernah tiba. Event yang sama dapat tiba dua kali atau tidak berurutan, jadi handler webhook memerlukan idempotensi dan pemeriksaan state.

Buku panduan ini menghubungkan pola itu dengan publishing yang andal. Sistem yang memperbarui basis datanya dan mengirim event Kafka atau webhook keluar dalam langkah terpisah dapat gagal di antara keduanya. Panduan ini menjelaskan pola outbox, change data capture, dan event sourcing sebagai jawaban praktis. Alat seperti Debezium, AWS Database Migration Service, Temporal, Camunda, dan AWS Step Functions mencakup sebagian ruang itu, meskipun masing-masing membawa model dan beban operasionalnya sendiri.

Rekonsiliasi bertindak sebagai penyangga akhir. Buku panduan ini mendorong tim untuk membandingkan buku besar mereka dengan pemroses, bank, kustodian, blockchain, dan sumber independen lainnya. Ketidaksesuaian dapat berarti data hilang, jumlah berbeda, penyelesaian usang, atau transfer batch satu-ke-banyak. Panduan ini memperingatkan agar tidak menimpa satu sisi demi membuat laporan terlihat hijau. Insinyur membutuhkan koreksi kelas utama, jalur pemrosesan ulang, dan logika pencocokan yang menghormati waktu penyelesaian.

Bagian kontrol memperluas gagasan ketidakpercayaan ke karyawan dan sistem di dalam perusahaan. Operasi uang yang sensitif, perubahan biaya, deployment produksi, dan perubahan infrastruktur mungkin memerlukan segregation of duties atau persetujuan maker-checker. Persetujuan itu sendiri perlu dicatat: peminta, pemberi persetujuan, alasan, cap waktu, dan bukti bahwa orang yang sama tidak menjalankan kedua peran. Kontrol akses menerima perlakuan yang sama melalui least privilege, role-based access, jejak perubahan, dan tinjauan berkala.

Pengujian menutup buku panduan ini dengan teknik yang lebih cocok untuk state keuangan daripada sekadar pemeriksaan berbasis contoh. Property-based testing dapat menghasilkan urutan operasi dan menegaskan bahwa pembukuan seimbang setelah setiap langkah. Crash injection dapat mematikan alur panjang di antara tiap pasangan langkah dan membuktikan bahwa worker bisa melanjutkannya. Golden test dapat mengunci rincian biaya atau pernyataan ke output yang sudah ditinjau. Uji kompatibilitas mundur dapat menjaga payload event lama tetap terbaca setelah perubahan skema.

Contoh end-to-end dalam buku panduan ini membuat pola-pola tersebut konkret. Penarikan kripto menggabungkan pengajuan idempotent, reservasi dana, pemeriksaan kepatuhan, broadcast on-chain, kedalaman konfirmasi, posting buku besar, penyelesaian biaya, dan rekonsiliasi chain. Deposit kartu menunjukkan mengapa sebuah platform seharusnya memperlakukan webhook capture sebagai sinyal, mengkredit melalui akun clearing, menunggu penyelesaian, dan menangani chargeback melalui pembalikan yang tertaut. Konversi dalam aplikasi dengan cashback menunjukkan mengapa spread, pembulatan, reference rate, dan uang promosi semuanya memerlukan entri buku besar.

Proyek ini tidak mengumumkan pendanaan, investor, atau peluncuran komersial. Posisi pasarnya datang dari celah yang berbeda: banyak insinyur masuk ke fintech dengan keterampilan sistem terdistribusi yang kuat tetapi minim paparan terhadap akuntansi, penyelesaian, kustodi, pemeriksaan sanksi, chargeback, dan bukti audit. Buku panduan ini mengemas kekhawatiran-kekhawatiran itu sebagai pola perangkat lunak, bukan cerita rakyat keuangan.

Itulah yang membuat panduan ini berguna melampaui startup fintech. Setiap tim yang menyimpan saldo, memindahkan aset, mengkredit dana promosi, menerbitkan laporan keuangan, atau berintegrasi dengan penyedia pembayaran menghadapi tekanan yang sama. Perangkat lunak uang gagal di celah antara layanan, cap waktu, retry, dan override manusia. Buku panduan ini memberi insinyur kosakata untuk celah-celah itu dan serangkaian kontrol yang bisa mereka ubah menjadi kode.