Payment Gateway: Fitur Standar, Tantangan Desain, dan Trade-off

18 Sep 2026

Benchmark Payment Gateway Bagian 7 : Status per VA, Bukan Cuma per Tagihan

04 Aug 2026

Bagian 6 ditutup dengan kalimat “kali ini betulan selesai — sampai draf berikutnya ditinjau ulang lagi.” Ternyata ungkapan itu bukan sekadar basa-basi. Saat merapikan poin-poin bernomor di Bagian 4 — yang menjelaskan cara kerja transaksi atomic pada RocksDB — muncul satu pertanyaan yang rupanya membongkar celah nyata di dalam kode, bukan sekadar ketidaktepatan pilihan kata.

Benchmark Payment Gateway Bagian 6 : Ditemukan Saat Menulis Bagian 5, Dibongkar dan Dibangun Ulang

03 Aug 2026

Seri ini seharusnya selesai di Bagian 5. Draft-nya sudah lengkap, angkanya sudah final, kesimpulannya sudah ditulis. Tapi ada satu paragraf soal trade-off “model detect-and-flag” yang, waktu ditinjau ulang, terasa mengganjal — dan pertanyaan yang muncul dari situ membongkar sesuatu yang lebih dalam daripada bug yang sudah dibahas di Bagian 4. Bagian ini isinya cerita soal itu: bagaimana proses menulis perbandingan arsitektur ini sendiri yang justru menemukan celah desain berikutnya, dan apa yang akhirnya dibongkar serta dibangun ulang karenanya.

Benchmark Payment Gateway Bagian 5 : Keputusan Final, dan Kenapa Repo Kafka-nya Tetap Kami Pertahankan

02 Aug 2026

Seri ini berawal dari pertanyaan mendasar: untuk payment gateway, apakah lebih tepat menggunakan PostgreSQL konvensional atau pendekatan event-sourced berbekal Kafka? Bagian 1 hingga 4 telah memaparkan pembuktian berbasis data empiris, lengkap dengan lika-liku salah tafsir dan proses koreksinya. Pada bagian penutup ini, mari kita rangkum hasil akhirnya sekaligus mengulas pertanyaan yang tak kalah menarik: jika RDBMS yang terpilih, mengapa repositori berbasis Kafka tersebut tetap dipertahankan?

Benchmark Payment Gateway Bagian 4 : "Nggak Boleh Double Payment, Walaupun Resource Habis"

01 Aug 2026

Di Bagian 3, dokumen ralat telah diterbitkan: hasil benchmark yang semula tampak dramatis (penurunan performa signifikan pada event-sourced beserta anomali pembayaran ganda) dipastikan sebagai efek samping rebutan resource dengan aplikasi lain. Begitu lingkungan pengujian dibersihkan, kedua anomali tersebut tak lagi muncul.

Benchmark Payment Gateway Bagian 3 : Ketika Benchmark Menipu Diri Sendiri

31 Jul 2026

Di Bagian 2, indikator benchmark yang bermasalah telah dibongkar dan diperbaiki. Kini saatnya mengeksekusi pengujian yang sesungguhnya. Bagian ini menyajikan dinamika yang cukup emosional: mulai dari ditemukannya bug domain penting berkat komparasi dua versi sistem, hingga fenomena benchmark dramatis yang ternyata dipicu oleh kesibukan internal komputer penguji.

Benchmark Payment Gateway Bagian 2 : Membangun Pembanding, dan Ketahuan Isinya Palsu

30 Jul 2026

Di bagian pertama, kami sepakat di atas kertas untuk memilih arsitektur monolith relasional (PostgreSQL). Kendati demikian, kami tetap membangun versi pembanding berarsitektur event-sourced agar keputusan tersebut teruji dengan angka empiris. Repo pembanding ini diberi nama payment-gateway-evtsrc (open source, lisensi Apache 2.0). Implementasi awal beserta skenario pengujiannya sebagian besar dikerjakan oleh Gemini Flash melalui Antigravity CLI.

Benchmark Payment Gateway Bagian 1 : Kenapa Dibandingkan Dulu Sebelum Dibangun

29 Jul 2026

Setiap kali kami di ArtiVisi membangun sistem yang berurusan dengan uang, pertanyaan ini hampir selalu datang dari internal tim engineering: “Kenapa tidak pakai event sourcing saja?” Pertimbangan teknis seperti skalabilitas atau audit trail otomatis dari event log sering mengemuka, di samping daya tarik arsitekturnya yang modern untuk portofolio.

Workshop Penggunaan Claude Code Untuk Meningkatkan Kinerja Akademik Dosen

12 Apr 2026