[{"data":1,"prerenderedAt":161},["ShallowReactive",2],{"site-header":3,"site-footer-license":42,"article-jawaban-kunci-itu-milik-faktanya-with-latest":46},{"navigations":4},[5,20,37],{"collection":6,"item":7},"series",{"__typename":6,"title":8,"slug":9,"children_series":10},"Artikel","all",[11,14,17],{"title":12,"slug":13},"Algoritma dan Struktur Data","algoritma-struktur-data",{"title":15,"slug":16},"Kecerdasan Artifisial","kecerdasan-artifisial",{"title":18,"slug":19},"Konsep Dasar Pemrograman","konsep-dasar-pemrograman",{"collection":6,"item":21},{"__typename":6,"title":22,"slug":23,"children_series":24},"Tutorial","tutorial",[25,28,31,34],{"title":26,"slug":27},"Belajar Java","belajar-java",{"title":29,"slug":30},"Belajar Pascal","belajar-pascal",{"title":32,"slug":33},"Belajar Golang","belajar-golang",{"title":35,"slug":36},"Belajar Python","belajar-python",{"collection":6,"item":38},{"__typename":6,"title":39,"slug":40,"children_series":41},"Lab","lab",[],{"name":43,"url":44,"show":45},"CC BY-SA","https://creativecommons.org/licenses/by-sa/4.0/",false,{"article":47,"renderedBody":92,"renderedTakeaway":93,"latestArticles":94,"toc":138},{"prerequisite":48,"id":52,"title":53,"slug":54,"excerpt":55,"published_at":56,"thumbnail_image":56,"tags":57,"reading_time":62,"takeway":63,"body":64,"authors":65,"series":71},{"id":49,"title":50,"slug":51},"116","Webhook-nya Telat, Job Rekonsiliasinya Keburu Jalan","webhook-telat-job-rekonsiliasi-keburu-jalan","117","Jawabannya: Kunci Itu Milik Faktanya","jawaban-kunci-itu-milik-faktanya","Kuncinya pindah dari pesan ke pembayaran, dan dua jalur itu butuh kebijakan yang berbeda waktu menemukan keanehan. Angka tiap variannya ada di sini.",null,[58,59,60,61,40],"idempotency","reconciliation","webhook","postgres",4,"Klaimnya harus tentang pembayaran (`charge_id`), bukan tentang pesannya (`event_id`).\n- Satu jalur punya tabel klaimnya sendiri = dua kebenaran; yang harus disatukan adalah kuncinya, bukan alatnya.\n- Webhook membalas jawaban pengiriman pertama; job melewati yang cocok dan melaporkan yang berbeda, bukan menimpanya.\n- Menghapus id run dari kunci juga menghapus kebutuhan akan kursor: mengulang satu hari penuh jadi aman.","## Hasil pengukuran\n\nSemua angka di sini dari run pengukuran, bukan perkiraan: satu database\nbersih untuk tiap varian. Pemeriksaannya 24.\n\n| varian | merah | catatan |\n|---|---|---|\n| kondisi awal | **14 dari 24** | kunci jalur webhook (`event_id`) dan kunci job (`recon:\u003Crun>:\u003Ccharge>`) nggak pernah bertemu |\n| klaim pindah ke `charge_id`, tapi job tetap punya tabel klaimnya sendiri | **13 dari 24** | bentuk gagalnya berubah: sekarang job-nya kena unique di ledger, jadi balasannya 500 |\n| nominal yang sudah tercatat ditimpa laporan | **3 dari 24** | barisnya tetap satu, tapi nominal yang benar sudah hilang tanpa jejak |\n| klaim per pembayaran di kedua jalur, dua kebijakan, tanpa kursor | **0 dari 24** | — |\n\nAngka konkret dari `make demo` di kondisi awal (enam pembayaran seharga 220.000): 12 baris untuk 6\npembayaran, saldo 665.000. Di branch `solusi`: satu baris per pembayaran, saldo tepat.\n\n## 1. Setiap bagian benar sendiri-sendiri. Itu masalahnya\n\nJalur webhook itu jawaban lab sebelumnya, dan tetap benar — untuk pertanyaan *\"apakah pesan ini\nsudah pernah saya terima?\"*\n\nJalur rekonsiliasi juga benar untuk pertanyaan yang dia jawab: *\"apakah run ini sudah memproses\nbaris laporan ini?\"* Karena id run selalu baru, jawabannya selalu \"belum\" — dan di situlah bugnya.\nJob yang dijalankan dua kali melaporkan `inserted=6` dua kali, dengan bangga.\n\nYang nggak pernah ada di sistem ini: satu tempat yang bisa menjawab **\"apakah pembayaran ini sudah\npernah saya catat?\"** Dua jalur, dua tabel, dua kebenaran.\n\n## 2. Kuncinya pindah dari pesan ke faktanya\n\n```\nsebelum:  processed_events(event_id PK)     satu pesan satu klaim\nsesudah:  payment_claims(charge_id PK)      satu pembayaran satu klaim\n```\n\n`charge_id` adalah kunci yang **sama** untuk kedua jalur, karena keduanya sedang membicarakan\npembayaran yang sama. `event_id` tetap disimpan — di ledger dan di baris klaimnya — tapi perannya\nberubah: dia jejak, bukan penentu.\n\nIkutannya di database: unique di `ledger_entries` pindah dari `event_id` ke `charge_id`, karena\nyang nggak boleh dua kali itu pembayarannya. Di produksi ini migrasi yang harus dikerjakan\nhati-hati: duplikat lamanya dibereskan dulu — dan itu keputusan bisnis, bukan keputusan SQL —\nbaru constraint-nya dipasang.\n\n## 3. Dua jalur, dua kebijakan\n\n| | klaim sudah ada, isinya sama | klaim sudah ada, nominal berbeda |\n|---|---|---|\n| **webhook** | balas jawaban pengiriman pertama (200) | **409** |\n| **job rekonsiliasi** | lewati (`skipped`) | **laporkan** di `mismatched`, jangan tulis apa pun |\n\nAlasannya beda penunggunya. Di ujung jalur webhook ada koneksi HTTP yang sedang menunggu jawaban:\ndia berhak dapat jawaban yang sama, dan kalau isinya bertentangan, 409 adalah jawaban yang benar.\nDi ujung jalur rekonsiliasi ada job yang sedang menyisir satu hari laporan: kalau satu baris jelek\nmembuat seluruh hari gagal, job-nya nggak akan pernah selesai — dan besok pagi baris yang sama akan\nmenggagalkannya lagi.\n\n## 4. Kursor itu gejala, bukan kebutuhan\n\nBegitu klaimnya per pembayaran, nggak ada lagi yang perlu dicatat tentang \"sudah sampai mana\".\nMenjalankan ulang satu hari penuh aman, dua run bersamaan aman (yang kalah klaim melewati baris\nitu), dan run yang cuma sempat dua baris bisa dilanjutkan oleh run berikutnya. Itu sebabnya tiga\npemeriksaan tentang run yang diulang, tumpang tindih, dan kepotong jadi hijau tanpa satu baris kode\ntambahan.\n\nKalimat \"kunci yang dimiliki faktanya, bukan pesannya\" itu saya baru ngerti setelah kena dua kali. Yang kedua lebih mahal, karena waktu itu saya sudah merasa sistemnya aman.\n\n## Jebakan yang sengaja dibiarkan\n\n**Memberi jalur kedua tabelnya sendiri.** Kelihatan paling rapi: kode jalur webhook nggak\ndisentuh, job punya tabelnya sendiri, nggak ada yang bertabrakan. Yang terjadi terukur: 13 dari 24\nmasih merah, dan bentuk gagalnya berubah — sekarang job-nya kena unique constraint di ledger, jadi\nbalasannya 500.\n\n**Menganggap laporan settlement sebagai kebenaran.** Varian \"yang tercatat ditimpa laporan\":\nbarisnya tetap satu, tapi nominal yang benar-benar terjadi sudah hilang tanpa jejak, dan saldonya\nsalah seribu. Kalau kamu memutuskan laporan memang lebih benar, keputusan itu boleh — tapi harus\ndisengaja, dan selisihnya tetap dicatat.\n\n**Menggagalkan job supaya \"kelihatan\".** Job yang melempar error di baris pertama laporan yang\njelek berhenti di situ selamanya, dan laporan hari itu nggak pernah selesai.\n\n## Pertanyaan buat kamu\n\n1. Job ini jalan tiap pagi untuk hari kemarin. Kalau gateway baru mengirim laporan hari itu tiga\n   hari kemudian, apa yang harus berubah — kode job-nya, atau jadwalnya?\n2. Kalau sebuah charge bisa punya dua fakta berbeda (refund setelah pembayaran), kunci apa yang\n   benar, dan kenapa `charge_id` sendirian nggak cukup?\n3. Webhook membalas 409 untuk nominal yang bertentangan, job melaporkannya. Apa yang lebih baik\n   untuk pengguna: baris penyesuaian otomatis, atau laporan harian yang harus dilihat manusia?\n4. Kalau tabel riwayat run dihapus sama sekali, apa yang hilang dari sistem ini? Jawab dulu sebelum\n   menghapusnya.\n",[66],{"authors_id":67},{"name":68,"slug":69,"role":70,"profile_picture":56},"Daffa Izzuddin","izzudd","Writer",{"id":72,"title":39,"slug":40,"articles":73,"parent_series":56},"29",[74,83,89],{"id":75,"title":76,"slug":77,"excerpt":78,"thumbnail_image":56,"tags":79},"104","Query-nya Tinggal 2, Tapi Response-nya Masih 1 Detik","query-tinggal-2-tapi-response-masih-1-detik","Endpoint feed yang cuma menampilkan 20 tulisan butuh satu detik, dan server database dihujani 41 query. Kamu kerjakan nasihat N+1 yang standar, query-nya turun jadi 2, dan latency-nya nggak bergerak. Ini versi \"apa adanya\" dari masalah itu, plus lab-nya.",[80,81,82],"database","performance","backend",{"id":84,"title":85,"slug":86,"excerpt":87,"thumbnail_image":56,"tags":88},"114","Saldo Naik Empat Kali untuk Satu Pembayaran","saldo-naik-empat-kali-untuk-satu-pembayaran","Kodenya nggak salah, dan gateway-nya juga nggak salah. Tapi satu pembayaran muncul empat kali di ledger. Coba tebak kenapa — lalu bikin `make check` hijau di lab-nya.",[58,60,61,80,40],{"id":49,"title":50,"slug":51,"excerpt":90,"thumbnail_image":56,"tags":91},"Jalur webhook sudah idempotent. Lalu ada job rekonsiliasi pagi, dan satu pembayaran tercatat dua kali dari dua jalur yang dua-duanya benar. Coba tebak kuncinya salah di mana.",[58,59,60,61,40],"\u003Ch2 id=\"hasil-pengukuran\">Hasil pengukuran\u003C/h2>\n\u003Cp>Semua angka di sini dari run pengukuran, bukan perkiraan: satu database\nbersih untuk tiap varian. Pemeriksaannya 24.\u003C/p>\n\u003Ctable>\n\u003Cthead>\n\u003Ctr>\n\u003Cth>varian\u003C/th>\n\u003Cth>merah\u003C/th>\n\u003Cth>catatan\u003C/th>\n\u003C/tr>\n\u003C/thead>\n\u003Ctbody>\u003Ctr>\n\u003Ctd>kondisi awal\u003C/td>\n\u003Ctd>\u003Cstrong>14 dari 24\u003C/strong>\u003C/td>\n\u003Ctd>kunci jalur webhook (\u003Ccode>event_id\u003C/code>) dan kunci job (\u003Ccode>recon:<run>:<charge>\u003C/code>) nggak pernah bertemu\u003C/td>\n\u003C/tr>\n\u003Ctr>\n\u003Ctd>klaim pindah ke \u003Ccode>charge_id\u003C/code>, tapi job tetap punya tabel klaimnya sendiri\u003C/td>\n\u003Ctd>\u003Cstrong>13 dari 24\u003C/strong>\u003C/td>\n\u003Ctd>bentuk gagalnya berubah: sekarang job-nya kena unique di ledger, jadi balasannya 500\u003C/td>\n\u003C/tr>\n\u003Ctr>\n\u003Ctd>nominal yang sudah tercatat ditimpa laporan\u003C/td>\n\u003Ctd>\u003Cstrong>3 dari 24\u003C/strong>\u003C/td>\n\u003Ctd>barisnya tetap satu, tapi nominal yang benar sudah hilang tanpa jejak\u003C/td>\n\u003C/tr>\n\u003Ctr>\n\u003Ctd>klaim per pembayaran di kedua jalur, dua kebijakan, tanpa kursor\u003C/td>\n\u003Ctd>\u003Cstrong>0 dari 24\u003C/strong>\u003C/td>\n\u003Ctd>—\u003C/td>\n\u003C/tr>\n\u003C/tbody>\u003C/table>\n\u003Cp>Angka konkret dari \u003Ccode>make demo\u003C/code> di kondisi awal (enam pembayaran seharga 220.000): 12 baris untuk 6\npembayaran, saldo 665.000. Di branch \u003Ccode>solusi\u003C/code>: satu baris per pembayaran, saldo tepat.\u003C/p>\n\u003Ch2 id=\"1-setiap-bagian-benar-sendiri-sendiri-itu-masalahnya\">1. Setiap bagian benar sendiri-sendiri. Itu masalahnya\u003C/h2>\n\u003Cp>Jalur webhook itu jawaban lab sebelumnya, dan tetap benar — untuk pertanyaan \u003Cem>"apakah pesan ini\nsudah pernah saya terima?"\u003C/em>\u003C/p>\n\u003Cp>Jalur rekonsiliasi juga benar untuk pertanyaan yang dia jawab: \u003Cem>"apakah run ini sudah memproses\nbaris laporan ini?"\u003C/em> Karena id run selalu baru, jawabannya selalu "belum" — dan di situlah bugnya.\nJob yang dijalankan dua kali melaporkan \u003Ccode>inserted=6\u003C/code> dua kali, dengan bangga.\u003C/p>\n\u003Cp>Yang nggak pernah ada di sistem ini: satu tempat yang bisa menjawab \u003Cstrong>"apakah pembayaran ini sudah\npernah saya catat?"\u003C/strong> Dua jalur, dua tabel, dua kebenaran.\u003C/p>\n\u003Ch2 id=\"2-kuncinya-pindah-dari-pesan-ke-faktanya\">2. Kuncinya pindah dari pesan ke faktanya\u003C/h2>\n\n\u003Cdiv class=\"code-block-wrapper my-6 not-prose rounded-xl border-2 border-black dark:border-gray-600 shadow-neo overflow-hidden bg-[#24292e] text-[#e1e4e8] transition-all\">\n  \u003Cdiv class=\"code-block-header flex items-center justify-between px-4 py-2.5 bg-[#1f2428] border-b-2 border-black dark:border-gray-600 font-mono text-xs font-bold text-gray-300 select-none\">\n    \u003Cdiv class=\"flex items-center gap-2\">\n      \u003Cspan class=\"w-3 h-3 rounded-full bg-[#ff5f56] border border-black/40 inline-block\">\u003C/span>\n      \u003Cspan class=\"w-3 h-3 rounded-full bg-[#ffbd2e] border border-black/40 inline-block\">\u003C/span>\n      \u003Cspan class=\"w-3 h-3 rounded-full bg-[#27c93f] border border-black/40 inline-block\">\u003C/span>\n      \u003Cspan class=\"ml-2 font-mono font-bold text-xs uppercase tracking-wider text-gray-300\">TEXT\u003C/span>\n    \u003C/div>\n    \u003Cbutton type=\"button\" class=\"copy-code-btn flex items-center gap-1.5 px-3 py-1 text-xs font-bold bg-[#2f363d] text-gray-200 border-2 border-black dark:border-gray-500 rounded-lg shadow-neo-sm hover:translate-x-0.5 hover:translate-y-0.5 hover:shadow-none hover:bg-gray-700 transition-all cursor-pointer\" data-code=\"sebelum%3A%20%20processed_events(event_id%20PK)%20%20%20%20%20satu%20pesan%20satu%20klaim%0Asesudah%3A%20%20payment_claims(charge_id%20PK)%20%20%20%20%20%20satu%20pembayaran%20satu%20klaim\" title=\"Salin kode\">\n      \u003Csvg class=\"w-3.5 h-3.5 copy-icon-svg\" fill=\"none\" stroke=\"currentColor\" viewBox=\"0 0 24 24\">\n        \u003Cpath stroke-linecap=\"round\" stroke-linejoin=\"round\" stroke-width=\"2\" d=\"M8 16H6a2 2 0 01-2-2V6a2 2 0 012-2h8a2 2 0 012 2v2m-6 12h8a2 2 0 002-2v-8a2 2 0 00-2-2h-8a2 2 0 00-2 2v8a2 2 0 002 2z\">\u003C/path>\n      \u003C/svg>\n      \u003Cspan class=\"copy-text\">Copy\u003C/span>\n    \u003C/button>\n  \u003C/div>\n  \u003Cdiv class=\"code-block-content p-4 overflow-x-auto text-sm font-mono leading-relaxed bg-[#24292e]\">\n    \u003Cpre class=\"shiki github-dark\" style=\"background-color:#24292e;color:#e1e4e8\">\u003Ccode>sebelum:  processed_events(event_id PK)     satu pesan satu klaim\nsesudah:  payment_claims(charge_id PK)      satu pembayaran satu klaim\u003C/code>\u003C/pre>\n  \u003C/div>\n\u003C/div>\u003Cp>\u003Ccode>charge_id\u003C/code> adalah kunci yang \u003Cstrong>sama\u003C/strong> untuk kedua jalur, karena keduanya sedang membicarakan\npembayaran yang sama. \u003Ccode>event_id\u003C/code> tetap disimpan — di ledger dan di baris klaimnya — tapi perannya\nberubah: dia jejak, bukan penentu.\u003C/p>\n\u003Cp>Ikutannya di database: unique di \u003Ccode>ledger_entries\u003C/code> pindah dari \u003Ccode>event_id\u003C/code> ke \u003Ccode>charge_id\u003C/code>, karena\nyang nggak boleh dua kali itu pembayarannya. Di produksi ini migrasi yang harus dikerjakan\nhati-hati: duplikat lamanya dibereskan dulu — dan itu keputusan bisnis, bukan keputusan SQL —\nbaru constraint-nya dipasang.\u003C/p>\n\u003Ch2 id=\"3-dua-jalur-dua-kebijakan\">3. Dua jalur, dua kebijakan\u003C/h2>\n\u003Ctable>\n\u003Cthead>\n\u003Ctr>\n\u003Cth>\u003C/th>\n\u003Cth>klaim sudah ada, isinya sama\u003C/th>\n\u003Cth>klaim sudah ada, nominal berbeda\u003C/th>\n\u003C/tr>\n\u003C/thead>\n\u003Ctbody>\u003Ctr>\n\u003Ctd>\u003Cstrong>webhook\u003C/strong>\u003C/td>\n\u003Ctd>balas jawaban pengiriman pertama (200)\u003C/td>\n\u003Ctd>\u003Cstrong>409\u003C/strong>\u003C/td>\n\u003C/tr>\n\u003Ctr>\n\u003Ctd>\u003Cstrong>job rekonsiliasi\u003C/strong>\u003C/td>\n\u003Ctd>lewati (\u003Ccode>skipped\u003C/code>)\u003C/td>\n\u003Ctd>\u003Cstrong>laporkan\u003C/strong> di \u003Ccode>mismatched\u003C/code>, jangan tulis apa pun\u003C/td>\n\u003C/tr>\n\u003C/tbody>\u003C/table>\n\u003Cp>Alasannya beda penunggunya. Di ujung jalur webhook ada koneksi HTTP yang sedang menunggu jawaban:\ndia berhak dapat jawaban yang sama, dan kalau isinya bertentangan, 409 adalah jawaban yang benar.\nDi ujung jalur rekonsiliasi ada job yang sedang menyisir satu hari laporan: kalau satu baris jelek\nmembuat seluruh hari gagal, job-nya nggak akan pernah selesai — dan besok pagi baris yang sama akan\nmenggagalkannya lagi.\u003C/p>\n\u003Ch2 id=\"4-kursor-itu-gejala-bukan-kebutuhan\">4. Kursor itu gejala, bukan kebutuhan\u003C/h2>\n\u003Cp>Begitu klaimnya per pembayaran, nggak ada lagi yang perlu dicatat tentang "sudah sampai mana".\nMenjalankan ulang satu hari penuh aman, dua run bersamaan aman (yang kalah klaim melewati baris\nitu), dan run yang cuma sempat dua baris bisa dilanjutkan oleh run berikutnya. Itu sebabnya tiga\npemeriksaan tentang run yang diulang, tumpang tindih, dan kepotong jadi hijau tanpa satu baris kode\ntambahan.\u003C/p>\n\u003Cp>Kalimat "kunci yang dimiliki faktanya, bukan pesannya" itu saya baru ngerti setelah kena dua kali. Yang kedua lebih mahal, karena waktu itu saya sudah merasa sistemnya aman.\u003C/p>\n\u003Ch2 id=\"jebakan-yang-sengaja-dibiarkan\">Jebakan yang sengaja dibiarkan\u003C/h2>\n\u003Cp>\u003Cstrong>Memberi jalur kedua tabelnya sendiri.\u003C/strong> Kelihatan paling rapi: kode jalur webhook nggak\ndisentuh, job punya tabelnya sendiri, nggak ada yang bertabrakan. Yang terjadi terukur: 13 dari 24\nmasih merah, dan bentuk gagalnya berubah — sekarang job-nya kena unique constraint di ledger, jadi\nbalasannya 500.\u003C/p>\n\u003Cp>\u003Cstrong>Menganggap laporan settlement sebagai kebenaran.\u003C/strong> Varian "yang tercatat ditimpa laporan":\nbarisnya tetap satu, tapi nominal yang benar-benar terjadi sudah hilang tanpa jejak, dan saldonya\nsalah seribu. Kalau kamu memutuskan laporan memang lebih benar, keputusan itu boleh — tapi harus\ndisengaja, dan selisihnya tetap dicatat.\u003C/p>\n\u003Cp>\u003Cstrong>Menggagalkan job supaya "kelihatan".\u003C/strong> Job yang melempar error di baris pertama laporan yang\njelek berhenti di situ selamanya, dan laporan hari itu nggak pernah selesai.\u003C/p>\n\u003Ch2 id=\"pertanyaan-buat-kamu\">Pertanyaan buat kamu\u003C/h2>\n\u003Col>\n\u003Cli>Job ini jalan tiap pagi untuk hari kemarin. Kalau gateway baru mengirim laporan hari itu tiga\nhari kemudian, apa yang harus berubah — kode job-nya, atau jadwalnya?\u003C/li>\n\u003Cli>Kalau sebuah charge bisa punya dua fakta berbeda (refund setelah pembayaran), kunci apa yang\nbenar, dan kenapa \u003Ccode>charge_id\u003C/code> sendirian nggak cukup?\u003C/li>\n\u003Cli>Webhook membalas 409 untuk nominal yang bertentangan, job melaporkannya. Apa yang lebih baik\nuntuk pengguna: baris penyesuaian otomatis, atau laporan harian yang harus dilihat manusia?\u003C/li>\n\u003Cli>Kalau tabel riwayat run dihapus sama sekali, apa yang hilang dari sistem ini? Jawab dulu sebelum\nmenghapusnya.\u003C/li>\n\u003C/ol>\n","\u003Cp>Klaimnya harus tentang pembayaran (\u003Ccode>charge_id\u003C/code>), bukan tentang pesannya (\u003Ccode>event_id\u003C/code>).\u003C/p>\n\u003Cul>\n\u003Cli>Satu jalur punya tabel klaimnya sendiri = dua kebenaran; yang harus disatukan adalah kuncinya, bukan alatnya.\u003C/li>\n\u003Cli>Webhook membalas jawaban pengiriman pertama; job melewati yang cocok dan melaporkan yang berbeda, bukan menimpanya.\u003C/li>\n\u003Cli>Menghapus id run dari kunci juga menghapus kebutuhan akan kursor: mengulang satu hari penuh jadi aman.\u003C/li>\n\u003C/ul>\n",[95,105,116,118,126,136],{"id":96,"title":97,"slug":98,"excerpt":99,"thumbnail_image":56,"tags":100},"113","Garbage Collector dituduh bikin aplikasi lemot. Seberapa adil tuduhan itu?","garbage-collector-dituduh-bikin-aplikasi-lemot","GC sering jadi tersangka utama tiap aplikasi melambat, dan banyak yang percaya dia jalan pakai timer tiap beberapa detik. Dua-duanya nggak sepenuhnya benar. Yuk bedah cara kerja GC dari dalam, plus satu pengecualian yang bikin Discord kesakitan tiap 2 menit. 🤔",[82,81,101,102,103,104],"golang","jvm","garbage-collector","memory",{"id":106,"title":107,"slug":108,"excerpt":109,"thumbnail_image":56,"tags":110},"111","Rust Masuk Kernel Linux: Revolusi Nyata atau Cuma Euforia RIIR?","rust-di-kernel-linux-revolusi-atau-cuma-hype","Selama lebih dari 30 tahun kernel Linux cuma mau bahasa C, lalu tiba-tiba Rust resmi masuk di Linux 6.1. Itu revolusi beneran atau cuma kebawa euforia meme Rewrite It In Rust? Yuk lihat datanya, bukan cuma opininya.",[111,112,113,114,115],"rust","linux","kernel","system-programming","memory-safety",{"id":84,"title":85,"slug":86,"excerpt":87,"thumbnail_image":56,"tags":117},[58,60,61,80,40],{"id":119,"title":120,"slug":121,"excerpt":122,"thumbnail_image":56,"tags":123},"112","Aplikasimu lambat, dan kamu udah kepikiran ganti bahasa. Tunggu dulu","aplikasimu-lambat-dan-kamu-udah-kepikiran-ganti-bahasa-tunggu-dulu","Ada endpoint yang grafiknya spike tiap beberapa menit, dan kepikiran buat pindah dari Go ke Rust? Discord dan Cloudflare beneran melakukannya — tapi cuma setelah kehabisan cara lain dan punya datanya. Yuk, bedah gejala mana yang beneran butuh rewrite, dan mana yang cuma butuh profiling. 🤔",[82,81,101,111,124,125],"system-design","profiling",{"id":127,"title":128,"slug":129,"excerpt":130,"thumbnail_image":56,"tags":131},"118","Belajar Idempotency dari Stok yang Keburu Kebeli","pub-sub-sendiri-lalu-belajar-idempotency","Tugas pertama saya di kerjaan pertama: sistem yang kewalahan menerima webhook. Saya putuskan membangun pub/sub sendiri dari nol, dan pelajaran yang akhirnya datang bukan dari situ — tapi dari stok gudang yang keburu kebeli orang.",[58,132,133,134,135],"event-driven","celery","rabbitmq","post-mortem",{"id":49,"title":50,"slug":51,"excerpt":90,"thumbnail_image":56,"tags":137},[58,59,60,61,40],[139,143,146,149,152,155,158],{"text":140,"depth":141,"id":142},"Hasil pengukuran",2,"hasil-pengukuran",{"text":144,"depth":141,"id":145},"1. Setiap bagian benar sendiri-sendiri. Itu masalahnya","1-setiap-bagian-benar-sendiri-sendiri-itu-masalahnya",{"text":147,"depth":141,"id":148},"2. Kuncinya pindah dari pesan ke faktanya","2-kuncinya-pindah-dari-pesan-ke-faktanya",{"text":150,"depth":141,"id":151},"3. Dua jalur, dua kebijakan","3-dua-jalur-dua-kebijakan",{"text":153,"depth":141,"id":154},"4. Kursor itu gejala, bukan kebutuhan","4-kursor-itu-gejala-bukan-kebutuhan",{"text":156,"depth":141,"id":157},"Jebakan yang sengaja dibiarkan","jebakan-yang-sengaja-dibiarkan",{"text":159,"depth":141,"id":160},"Pertanyaan buat kamu","pertanyaan-buat-kamu",1791651539103]