[{"data":1,"prerenderedAt":459},["ShallowReactive",2],{"site-header":3,"site-footer-license":37,"article-database-sharding-vs-partitioning-kapan-data-perlu-dipecah-with-latest":41},{"navigations":4},[5,20],{"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},"Konsep Dasar Pemrograman","konsep-dasar-pemrograman",{"title":18,"slug":19},"Kecerdasan Artifisial","kecerdasan-artifisial",{"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 Python","belajar-python",{"title":35,"slug":36},"Belajar Golang","belajar-golang",{"name":38,"url":39,"show":40},"CC BY-SA","https://creativecommons.org/licenses/by-sa/4.0/",false,{"article":42,"renderedBody":414,"renderedTakeaway":415,"latestArticles":416,"toc":439},{"id":43,"title":44,"slug":45,"excerpt":46,"published_at":47,"thumbnail_image":48,"tags":50,"reading_time":58,"takeway":59,"body":60,"authors":61,"series":68},"39","Database Sharding vs Partitioning: Kapan Data Perlu Dipecah?","database-sharding-vs-partitioning-kapan-data-perlu-dipecah","Tabel transaksi kalian udah nembus miliaran baris dan tiap *query* laporan bikin *CPU* melonjak 100%? Sebelum asal pecah data, yuk kita pahami dulu beda *sharding* sama *partitioning*!","2026-08-24T06:17:10.104Z",{"id":49},"08ef5fe5-d935-47b3-bbbc-d976948b2a9e",[51,52,53,54,55,56,57],"backend","database","postgresql","system-design","architecture","sharding","scaling",5,"- *Table Partitioning* mecah tabel raksasa jadi partisi kecil di dalam satu *instance* database yang sama, biar *index* tetap enteng dan *query pruning* jalan.\n- *Database Sharding* nyebarin data ke banyak *server* terpisah (*horizontal scaling*) pas kapasitas satu mesin udah mentok.\n- Pemilihan *sharding key*—entah *range-based*, *hash-based*, atau *directory-based*—nentuin apakah beban terbagi rata atau malah bikin *hotspot*.\n- Harga dari *sharding* itu mahal: *cross-shard join* hilang, transaksi terdistribusi butuh 2PC atau *Saga Pattern*, dan *re-sharding* jadi kerjaan yang bikin keringetan.","Tabel transaksi atau log aktivitas kalian udah nembus ratusan juta sampai miliaran *row*? Kalau iya, kita satu klub. 😅\n\nAwalnya, pas data masih ribuan *row*, semua *query* `SELECT` jalan secepat kilat. Tapi begitu ukuran tabel membengkak sampai puluhan *gigabyte*, semuanya berubah:\n\n- *Index B-Tree* nggak muat lagi di *RAM* (*buffer pool*).\n- Setiap `INSERT` baru mulai kerasa lambat gara-gara proses *index balancing* yang berat.\n- *Query* laporan bulanan bikin *CPU* database melonjak sampai 100% dan ngunci *row* lainnya.\n\nPas teknik optimasi standar kayak *indexing* dan *connection pooling* udah nggak mempan lagi, langkah arsitektur berikutnya adalah mecah data.\n\nNah, dua istilah yang paling sering muncul di sini adalah *Partitioning* dan *Sharding*. Kedengerannya mirip, sih, tapi arsitektur, tujuan, dan tingkat kerumitannya beda banget. Yuk, kita bedah satu-satu biar kalian nggak salah pilih.\n\n## Ibaratnya Kayak Apa, Sih?\n\nBiar gampang, bayangin pengelolaan berkas dokumen kantor.\n\n*Table Partitioning* itu kayak satu lemari arsip besar yang dikasih sekat laci. Berkasnya udah menumpuk setinggi gunung, jadi kalian pasang sekat bertanda Laci 2024, Laci 2025, dan Laci 2026. Semua tetap di lemari fisik yang sama—**satu *server* database**. Pas staf nyari surat Mei 2025, dia langsung buka Laci 2025 tanpa nyisir laci tahun lain. Proses instan inilah yang disebut *Partition Pruning*.\n\n*Database Sharding* itu beda cerita. Kalau lemarinya udah penuh sampai ruangan kantor nggak muat, kalian malah nyewa 3 gedung gudang terpisah: Jakarta, Surabaya, dan Medan. Berkas nasabah Jawa barat masuk Jakarta, Jawa timur masuk Surabaya, Sumatra masuk Medan. Datanya benar-benar tersebar di mesin fisik yang berbeda. Jadi, kalau gudang Jakarta kebanjiran, gudang Surabaya dan Medan tetap jalan normal.\n\n## Sebenernya Apa Sih *Table Partitioning* Itu?\n\n*Partitioning* itu fitur bawaan dari sistem manajemen database relasional modern kayak [PostgreSQL](https://www.postgresql.org/docs/current/ddl-partitioning.html) dan [MySQL](https://www.mysql.com/).\n\nSecara logis, aplikasi tetap lihat datanya sebagai satu tabel utuh—misal `orders`. Tapi secara fisik di level *disk*, database mecahnya jadi tabel-tabel partisi yang lebih kecil.\n\nTipe *partitioning* yang populer ada tiga:\n\n1. *Range Partitioning*—mecah data berdasarkan rentang nilai, paling umum berdasarkan tanggal. Contohnya `orders_2026_q1`, `orders_2026_q2`.\n2. *List Partitioning*—mecah data berdasarkan daftar nilai diskret, misal kode negara: ID, SG, MY.\n3. *Hash Partitioning*—mecah data secara merata pakai fungsi *modulo hash* dari kolom kunci.\n\nDi PostgreSQL, deklarasi partisinya ngangenin banget:\n\n```sql\n-- 1. Buat master table dengan partisi Range tanggal\nCREATE TABLE orders (\n    order_id BIGSERIAL,\n    customer_id BIGINT NOT NULL,\n    order_date DATE NOT NULL,\n    total_amount NUMERIC(12, 2),\n    status VARCHAR(20),\n    PRIMARY KEY (order_id, order_date)\n) PARTITION BY RANGE (order_date);\n\n-- 2. Buat partisi fisik untuk kuartal 1 & 2 tahun 2026\nCREATE TABLE orders_2026_q1 PARTITION OF orders\n    FOR VALUES FROM ('2026-01-01') TO ('2026-04-01');\n\nCREATE TABLE orders_2026_q2 PARTITION OF orders\n    FOR VALUES FROM ('2026-04-01') TO ('2026-07-01');\n```\n\nKetika aplikasi jalankan `SELECT * FROM orders WHERE order_date = '2026-02-15'`, PostgreSQL otomatis cuma memindai `orders_2026_q1` dan ngabaikan partisi lainnya. Itu *Partition Pruning* yang tadi kita singgung. 😎\n\nOh iya, perhatiin kolom `order_date` harus ikut jadi bagian *primary key*. Soalnya, PostgreSQL mewajibkan kolom partisi masuk ke *key* uniknya. Kalau nggak, `CREATE TABLE`-nya bakal langsung ngamuk.\n\n## Terus, *Database Sharding* Itu Apa Bedaannya?\n\nKalau *Partitioning* mecah tabel di dalam satu *server*, *Sharding* justru ngedistribusikan data ke banyak *server* database mandiri yang disebut *shard*.\n\nTiap *server shard* adalah *instance* database lengkap yang nyimpen subset data tertentu. Arsitektur ini **bentuk sejati dari *Horizontal Scaling*** (*Scale-Out*).\n\nKunci suksesnya adalah milih *sharding key* yang tepat buat memetakan data ke *shard* tujuan:\n\n1. *Hash-Based Sharding*—hitung nilai *hash* dari ID, misal `hash(user_id) % jumlah_shard`. Distribusinya merata, tapi *range query* jadi susah. Buat nambah atau ngurangin jumlah *shard* tanpa bikin data berantakan, teknik *consistent hashing* sering dipakai.\n2. *Range-Based Sharding*—mecah berdasarkan rentang alfabet atau wilayah, misal *user* A–M di Shard 1 dan N–Z di Shard 2. Rentan bikin *Hotspot Shard* kalau satu kelompok data jauh lebih aktif.\n3. *Directory / Lookup-Based Sharding*—nyimpen tabel pemetaan terpusat (*lookup service*) yang nyatet ID mana ada di *shard* mana. Fleksibel banget, tapi tabel *lookup*-nya bisa jadi *single point of failure* dan *bottleneck* baru.\n\n## Apa Aja Sih Susahnya *Sharding*?\n\n**Jangan buru-buru *sharding*** sebelum benar-benar kepepet, ya. Kerumitan arsitekturnya bukan main. 😅\n\nPertama, kita kehilangan *Cross-Shard JOIN*. Tabel pelanggan di Shard A dan tabel transaksi di Shard B **nggak bisa lagi di-*JOIN* pakai SQL biasa**. *Query*-nya harus digabung manual di level aplikasi backend (*Application-Level Join*).\n\nKedua, muncul urusan transaksi terdistribusi. Menjamin prinsip ACID di beberapa *server* fisik butuh protokol *Two-Phase Commit* (2PC) atau *Saga Pattern* yang ribet dan lambat.\n\nKetiga, ada *Re-Sharding*. Pas kapasitas 4 *shard* udah penuh dan kalian mau nambah jadi 8, memindahkan data lama antar *server* (*data rebalancing*) tanpa *downtime* itu pekerjaan yang bikin keringetan.\n\nBiar nggak bikin pusing sendiri, ekosistem cloud modern nyediain *middleware* terdistribusi kayak [Vitess](https://vitess.io/) buat MySQL skala raksasa, [Citus Data](https://www.citusdata.com/) buat PostgreSQL, atau database *NewSQL* kayak [CockroachDB](https://www.cockroachlabs.com/).\n\n## Kapan Pakai *Partitioning*, Kapan Baru *Sharding*?\n\nPenskalaan database itu perjalanan bertahap, jadi **urutannya penting**:\n\n1. Optimasi dulu yang murah: rapikan *query*, pasang *index* komposit, dan *cache* data panas (*hot data*) di Redis.\n2. Baru pakai *Table Partitioning* kalau data historis—log, *audit trail*, order lama—mulai menumpuk di satu *server*, dan kapasitas *disk* maupun *RAM*-nya masih cukup. Bonusnya, hapus data kedaluwarsa jadi cepet: `DROP TABLE` partisi lama jauh lebih gesit ketimbang `DELETE FROM ... WHERE date \u003C ...`.\n3. *Database Sharding* cuma kalau volume data dan *write throughput* udah ngelewatin kapasitas mesin terbesar yang bisa disewa (*Vertical Scale Limit*), atau sistem butuh isolasi data per wilayah geografis (*data residency compliance*).\n\n## Jadi, Kapan Data Bener-bener Perlu Dipecah?\n\n*Partitioning* itu langkah rapi buat ngatur tabel raksasa yang masih betah di satu mesin. Sedangkan *sharding* adalah **senjata pamungkas**, dipakai pas satu *server* bener-bener udah nggak mampu lagi.\n\nMulailah dari yang murah: optimasi *query*, *connection pool*, dan *caching*. Naik ke *partitioning* kalau dirasa perlu. Baru deh, pertimbangkan *sharding* kalau sistem udah menembus skala jutaan transaksi per detik di panggung global.\n\nSelamat ber-*scaling* ria, dan semoga data kalian tetap rapi tersimpan di laci-laci *shard*-nya! 👋",[62],{"authors_id":63},{"name":64,"slug":65,"role":66,"profile_picture":67},"Inva","inva","Writer",null,{"id":69,"title":8,"slug":9,"articles":70,"parent_series":67},"9",[71,85,97,109,120,133,143,154,166,177,188,198,208,219,228,239,250,260,268,279,290,301,309,318,327,340,349,360,371,381,390,399,402],{"id":72,"title":73,"slug":74,"excerpt":75,"thumbnail_image":76,"tags":78},"41","Log Aggregation Modern dengan Grafana Loki dan Vector: Hemat Storage Tanpa Indeks Raksasa","log-aggregation-modern-grafana-loki-vector-hemat-storage","Klaster Elasticsearch kalian rakus RAM dan boros storage, ya? Padahal nggak semua kata di log perlu diindeks, lho. Yuk, kita kenalan sama duet Grafana Loki dan Vector yang jauh lebih ramah kantong!",{"id":77},"03c9d1a0-c80a-401d-9f2b-2b3ee7abb115",[51,79,80,81,82,83,84,54],"observa","logging","grafana","loki","vector","devops",{"id":86,"title":87,"slug":88,"excerpt":89,"thumbnail_image":90,"tags":92},"45","Rate Limiting Algorithms: Token Bucket vs Leaky Bucket vs Sliding Window","rate-limiting-algorithms-token-bucket-leaky-bucket-sliding-window","Udah tahu kenapa *rate limiting* itu wajib, tapi masih bingung beda Token Bucket, Leaky Bucket, Fixed Window, dan Sliding Window? Yuk, kita adu empat algoritma ini bareng-bareng dan cari tahu mana yang paling pas buat API kalian!",{"id":91},"0e0ed26d-20c6-443c-bde1-4a6200f6f801",[51,54,93,94,95,55,96],"rate-limiting","redis","api-gateway","traffict-management",{"id":98,"title":99,"slug":100,"excerpt":101,"thumbnail_image":102,"tags":104},"16","Menggunakan TypeScript dengan Node.js dan Express","menggunakan-typescript-dengan-node-js-dan-express","Pengen bikin server Express di Node.js tapi pakai fitur-fitur keren TypeScript? Yuk, intip cara setup lengkapnya dari nol di sini!",{"id":103},"798b60f1-9ef5-4f73-8d43-85825fd86acc",[105,106,107,108],"javascript","nodejs","express","typescript",{"id":110,"title":111,"slug":112,"excerpt":113,"thumbnail_image":114,"tags":116},"17","Pemrograman Asynchronous vs Multithreading, Apa Sih Bedanya?","pemrograman-asynchronous-dan-multithreading-apa-bedanya","Sering dengar istilah asynchronous dan multithreading pas ngoding tapi masih bingung bedanya? Yuk, kita bedah perbedaannya lewat analogi bikin mi instan yang gampang dipahami!",{"id":115},"9c05d0ae-e829-4f1b-b9f7-a84f3e0439d3",[117,118,119],"pemrograman","concurrency","tips-coding",{"id":121,"title":122,"slug":123,"excerpt":124,"thumbnail_image":125,"tags":127},"33","Berkenalan dengan RabbitMQ: Si Kurir Pesan Serba Bisa","berkenalan-dengan-rabbitmq-si-kurir-pesan-serba-bisa","Pernah nggak sih kalian klik Bayar Sekarang dan notifikasi suksesnya muncul seketika, padahal email konfirmasi baru nyampe beberapa detik kemudian? Rahasianya ada di satu kurir tak terlihat. Yuk, kita kenalan sama RabbitMQ!",{"id":126},"f6620f79-b3b2-4f9c-8104-283a335e06c4",[128,129,51,130,131,132],"rabbitmq","message-broker","microservices","async","queue",{"id":134,"title":135,"slug":136,"excerpt":137,"thumbnail_image":138,"tags":140},"34","Kenapa Backend Butuh Database Connection Pooling?","kenapa-backend-butuh-database-connection-pooling","Pernah kena error Too many connections padahal CPU server masih santai di angka 30%? Masalahnya bukan di query kalian, tapi di cara aplikasi ngobrol sama database. Yuk, kenalan sama Connection Pooling!",{"id":139},"6f7a2d8c-2a37-4901-a522-50df8d9c0a20",[51,52,53,141,54,142],"connection-pooling","performance",{"id":144,"title":145,"slug":146,"excerpt":147,"thumbnail_image":148,"tags":150},"27","Background Worker & Task Queue: Jangan Jalankan Proses Berat di Request HTTP!","background-worker-task-queue-jangan-jalankan-proses-berat-di-http","Pernah nggak sih kalian klik Daftar Akun lalu halaman loading muter sampai 15 detik tanpa kepastian? Penyebabnya klasik banget. Yuk, kita bahas kenapa proses berat nggak boleh dijalanin di request HTTP!",{"id":149},"e119c6ad-fc37-4b92-abdc-3eb20f8e34b4",[51,151,152,153,128,94,131],"task-queue","celery","fastapi",{"id":155,"title":156,"slug":157,"excerpt":158,"thumbnail_image":159,"tags":161},"28","Mengatasi N+1 Query Problem: Musuh Tersembunyi Performa Backend","mengatasi-n-plus-1-query-problem-musuh-tersembunyi-backend","Pernah bikin endpoint yang cuma nampilin 50 postingan beserta nama penulisnya, tapi response-nya lambat banget? Bisa jadi kalian kena N+1 Query. Yuk, kita bedah penyebabnya dan cara memberantasnya!",{"id":160},"34b94e14-3e9a-4778-9f1f-6df5898915fb",[52,162,163,164,165,142,51],"sql","orm","sqlalchemy","django",{"id":167,"title":168,"slug":169,"excerpt":170,"thumbnail_image":171,"tags":173},"30","Berkenalan dengan Bahasa Go: Kenapa Banyak Dipakai untuk Backend Modern?","berkenalan-dengan-bahasa-go-untuk-backend-modern","Kok bisa sih Go yang masih muda ini jadi bahasa andalan Docker sampai Kubernetes? Yuk, kita kenalan sama Goroutine, Channel, dan alasan dia hemat memori luar biasa!",{"id":172},"a368631c-f331-4c50-8322-1d0fc44927aa",[174,175,51,118,176,54],"golang","go","goroutine",{"id":178,"title":179,"slug":180,"excerpt":181,"thumbnail_image":182,"tags":184},"13","Hal yang Perlu Diperhatikan Sebelum Pindah ke Linux","hal-yang-perlu-diperhatikan-sebelum-pindah-ke-linux","Tertarik migrasi dari Windows ke Linux tapi masih ragu? Yuk, pelajari kelebihan, kekurangan, dan persiapan penting sebelum kamu benar-benar pindah!",{"id":183},"ae27713e-5025-4d13-88b6-efb4860cc5b3",[185,186,187],"linux","windows","foss",{"id":189,"title":190,"slug":191,"excerpt":192,"thumbnail_image":193,"tags":195},"11","Apa Kabar JavaScript? Rilis State of JS 2022","apa-kabar-javascript-rilis-state-of-js-2022","Survei State of JS 2022 resmi dirilis dengan lonjakan responden yang luar biasa! Framework dan build tool apa saja yang berhasil mencuri perhatian tahun ini?",{"id":194},"18df5262-d813-43d1-b1f7-5595a7f53602",[105,196,197],"web","news",{"id":199,"title":200,"slug":201,"excerpt":202,"thumbnail_image":203,"tags":205},"12","Buat PowerShell Lebih Berwarna dengan Starship","buat-powershell-lebih-berwarna-dengan-starship","Bosen sama tampilan PowerShell yang hitam putih dan kaku? Yuk, sulap terminalmu jadi lebih interaktif, estetik, dan berwarna pakai Starship!",{"id":204},"c5a8262b-43db-4479-8f6c-5a6a0d61653b",[206,186,207],"shell","powershell",{"id":209,"title":210,"slug":211,"excerpt":212,"thumbnail_image":213,"tags":215},"14","Instalasi Java dengan Visual Studio Code","instalasi-java-dengan-visual-studio-code","Mau belajar ngoding Java tapi spek laptop pas-pasan buat buka IDE berat? Yuk, cari tahu cara setup VS Code biar ngoding Java tetap lancar dan enteng!",{"id":214},"99b01cc2-11ac-4449-9927-a1a7116347df",[216,217,218],"howto","java","editor",{"id":220,"title":221,"slug":222,"excerpt":223,"thumbnail_image":224,"tags":226},"15","Kenapa Ada Banyak Sekali Distro Linux?","kenapa-ada-banyak-sekali-distro-linux","Pernah bingung pas mau install Linux tapi malah disuguhi puluhan pilihan distro? Tenang, kalian nggak sendirian. Yuk, cari tahu kenapa distro Linux bisa sebanyak itu dan apa bedanya!",{"id":225},"b5352a4b-f274-4489-aca9-36814947d514",[185,227],"distro",{"id":229,"title":230,"slug":231,"excerpt":232,"thumbnail_image":233,"tags":235},"18","React, Angular, atau Vue: Pilih Framework yang Mana?","react-angular-vue-pilih-framework-yang-mana","Bingung menentukan pilihan di antara React, Angular, dan Vue untuk proyek web kalian berikutnya? Tenang, yuk kita bandingkan kelebihan masing-masing di sini!",{"id":234},"ff111270-80c2-4ccb-83d7-d5ab8c021201",[236,237,238],"web-development","frontend","framework",{"id":240,"title":241,"slug":242,"excerpt":243,"thumbnail_image":244,"tags":246},"19","Static Typing dan Dynamic Typing: Apa Bedanya?","static-typing-dan-dynamic-typing-apa-bedanya","Pernah bingung kenapa di Java tipe data harus dideklarasikan, sementara di Python tinggal pakai aja? Yuk, cari tahu perbedaan static typing dan dynamic typing di sini!",{"id":245},"98e85e76-9e7b-42d1-b989-7c75e7f49abc",[247,248,249],"programming","types","comparison",{"id":251,"title":252,"slug":253,"excerpt":254,"thumbnail_image":255,"tags":257},"20","Tailwind v3.0 Rilis: Ada JIT, Arbitrary Values, dan Banyak Lagi!","tailwind-v3-0-rilis-jit-arbitrary-dan-banyak-lagi","Tailwind CSS v3.0 resmi dirilis dengan segudang peningkatan performa yang bikin proses coding makin asyik. Apa aja sih fitur andalan yang wajib dicoba?",{"id":256},"d5e879fa-5cd0-4015-a155-b0cc69ff12fb",[258,259,236],"tailwind-css","css-framework",{"id":261,"title":262,"slug":263,"excerpt":264,"thumbnail_image":265,"tags":267},"21","TypeScript: JavaScript dengan Gaya dan Tipe Data Statis","typescript-javascript-dengan-gaya","Pernah pusing gara-gara runtime error di JavaScript? Yuk, kenalan dengan TypeScript yang bawa fitur static typing biar kode kalian makin rapi dan aman!",{"id":266},"f615bb1f-8e36-4d6c-9c2c-f1629407173c",[108,105,236],{"id":269,"title":270,"slug":271,"excerpt":272,"thumbnail_image":273,"tags":275},"22","Yang Baru di Nuxt 3: Nitro Engine, Vite, dan Fitur Keren Lainnya","yang-baru-di-nuxt-3-nitro-vite-dan-banyak-lagi","Nuxt 3 hadir membawa perubahan arsitektur besar-besaran untuk menyelaraskan dengan Vue 3. Penasaran apa saja peningkatan performa dan fitur barunya?",{"id":274},"8444bdbc-f60c-4d8b-8593-1b49400e8659",[276,277,278],"nuxt-3","vue-3","frontend-framework",{"id":280,"title":281,"slug":282,"excerpt":283,"thumbnail_image":284,"tags":286},"23","Kenapa Pakai FastAPI dan Kenapa Dia Kenceng Banget?","kenapa-pakai-fastapi-dan-kenapa-dia-kenceng-banget","Sering dengar FastAPI tapi masih bingung kenapa dia bisa ngebut kayak NodeJS dan Go? Yuk, kita bedah bareng rahasia ASGI, sihir Pydantic, sampai dokumentasi otomatisnya!",{"id":285},"84847c9e-70ab-4dcc-bed7-7be50165f7f4",[153,287,51,288,289],"python","asgi","pydantic",{"id":291,"title":292,"slug":293,"excerpt":294,"thumbnail_image":295,"tags":297},"26","REST API vs gRPC: Kapan Sebaiknya Mulai Pindah dari JSON?","rest-api-vs-grpc-kapan-sebaiknya-pindah-dari-json","Pernah nggak sih sistem mikroservis kalian mulai kerasa berat padahal cuma tuker-tukeran data internal? Belum tentu masalah servernya. Yuk, kita bahas kapan REST + JSON masih juara dan kapan gRPC jadi jawabannya!",{"id":296},"487500a0-9e09-469d-8736-1583c5ea83aa",[51,298,299,130,300,54],"grpc","rest-api","protobuf",{"id":302,"title":303,"slug":304,"excerpt":305,"thumbnail_image":306,"tags":308},"38","Optimistic vs Pessimistic Locking: Mengatasi Rebutan Data di Database","optimistic-vs-pessimistic-locking-mengatasi-rebutan-data-di-database","Seribu orang ngeklik \"Beli Sekarang\" di detik yang sama buat rebutan 1 tiket terakhir. Kira-kira apa yang bakal terjadi di server kalian? Yuk, kita banding *pessimistic* sama *optimistic locking*!",{"id":307},"21ab769d-6f82-4a22-be11-17ac16e9fb6b",[51,52,118,53,54,55,162],{"id":310,"title":311,"slug":312,"excerpt":313,"thumbnail_image":314,"tags":316},"24","Kenapa Butuh Rate Limiting?","kenapa-butuh-rate-limiting","Pernah nggak sih endpoint login kalian diserbu bot yang nyoba nembak ribuan password cuma dalam semenit? Yuk, kita bahas kenapa Rate Limiting itu wajib, plus cara masangnya di FastAPI!",{"id":315},"1401f9e5-6359-404a-8d80-273ddee9a372",[51,93,54,317,94,153],"api",{"id":319,"title":320,"slug":321,"excerpt":322,"thumbnail_image":323,"tags":325},"25","Kenapa Event Queue Bikin Backend Kalian Nggak Gampang Tumbang?","kenapa-event-queue-bikin-backend-kamu-nggak-gampang-tumbang","Pernah klik tombol Beli Sekarang dan notifikasi suksesnya muncul dalam sekejap, padahal di belakang layar ada invoice, email, sampai push notification yang harus dibuat? Rahasianya Event Queue. Yuk, kita bedah!",{"id":324},"d9e76018-fbcc-4c69-ad42-8f75ff229ecd",[51,54,326,129,55],"event-queue",{"id":328,"title":329,"slug":330,"excerpt":331,"thumbnail_image":332,"tags":334},"46","Mengapa C Mulai Ditinggalkan: Duel Filosofi Keamanan Rust vs Kesederhanaan Zig","mengapa-c-mulai-ditinggalkan-duel-filosofi-rust-vs-zig","Pernah denger kalau sekitar 70% celah keamanan kritis software modern itu asalnya dari bahasa C? Iya, bahasa yang udah jadi fondasi internet ini 😅. Yuk, kita bedah duel filosofi Rust vs Zig dan cari tahu mana yang pas buat proyek kalian!",{"id":333},"1942a5c9-c1f6-476d-9913-768f78d9d8eb",[335,336,337,338,339],"system-programming","rust","zig","c","memory-safety",{"id":341,"title":342,"slug":343,"excerpt":344,"thumbnail_image":345,"tags":347},"29","Memahami Database Indexing: Rahasia Query Super Cepat","memahami-database-indexing-rahasia-query-super-cepat","Query kalian mulai lelet padahal data baru nembus jutaan baris? Sebelum buru-buru *upgrade* server, yuk cek dulu *index*-nya. Yuk, kita bedah gimana *database indexing* sebenernya kerja!",{"id":346},"b123036f-1779-478c-a545-cf5f189b5fe9",[52,162,53,348,142,51],"indexing",{"id":350,"title":351,"slug":352,"excerpt":353,"thumbnail_image":354,"tags":356},"31","Mengenal Redis: Lebih dari Sekadar In-Memory Cache","mengenal-redis-lebih-dari-sekadar-in-memory-cache","Masih nganggep Redis cuma buat caching? Padahal dia bisa jadi leaderboard, message broker, sampai rate limiter lho. Yuk, kita bedah semua kemampuannya!",{"id":355},"9595b7d7-60e0-48f5-a715-f3cf60f34e1d",[94,51,357,358,359,287],"cache","nosql","in-memory",{"id":361,"title":362,"slug":363,"excerpt":364,"thumbnail_image":365,"tags":367},"32","Docker Compose untuk Developer Santai: Satu Perintah Buat Jalankan Semua Service","docker-compose-untuk-developer-santai","Pernah nggak kalian ngulang-ngulang perintah `docker run` cuma buat nyalain web, database, dan cache satu-satu? Capek, kan? Yuk, kita rapikan semuanya jadi satu file dan satu perintah!",{"id":366},"f4c08f1b-e0d0-410c-b091-c3618944fb3e",[368,369,84,370,51],"docker","docker-compose","containers",{"id":372,"title":373,"slug":374,"excerpt":375,"thumbnail_image":376,"tags":378},"35","Mengenal Idempotency Key: Rahasia Anti-Double Charge di API Pembayaran","mengenal-idempotency-key-rahasia-anti-double-charge-di-api-pembayaran","Pernah internet kalian ngadat pas lagi nekan tombol Bayar, terus panik ngekliknya tiga kali? Kalau endpoint-nya nggak idempotent, saldo bisa kepotong berkali-kali. Yuk, kenalan sama Idempotency Key!",{"id":377},"724cb83a-3ce5-4ee2-b0d7-533e3a0fc7df",[51,317,379,54,380,153,94],"idempotency","payment",{"id":382,"title":383,"slug":384,"excerpt":385,"thumbnail_image":386,"tags":388},"36","Mencegah Efek Domino di Mikroservis dengan Circuit Breaker Pattern","mencegah-efek-domino-di-mikroservis-dengan-circuit-breaker-pattern","Pernah nggak sih, satu fitur minor di aplikasi kalian mendadak lelet, eh malah bikin halaman checkout dan login ikut down total? Itu namanya *cascading failure*. Yuk, kita bahas gimana *circuit breaker pattern* (pemutus arus) nyelametin arsitektur kalian!",{"id":387},"c2e8e37f-8f9a-423f-a09d-74613b3c2924",[51,130,389,54,55],"circuit-breaker",{"id":391,"title":392,"slug":393,"excerpt":394,"thumbnail_image":395,"tags":397},"37","Kenapa Backend Butuh Graceful Shutdown? Jangan Asal Cabut Kabel Server!","kenapa-backend-butuh-graceful-shutdown-jangan-asal-cabut-kabel-server","Pernah nggak sih, abis kalian nge-*deploy* backend, beberapa detik kemudian monitoring malah banjir *alert* **502 Bad Gateway** dari pengguna? Saldo udah kepotong tapi status order belum keburu ter-*update* di *database*. Yuk, kita bahas kenapa *graceful shutdown* itu wajib banget!",{"id":396},"251a54a7-1d24-47fd-8cbc-a46fd42cbb6f",[51,84,153,368,398,54,55],"kubernetes",{"id":43,"title":44,"slug":45,"excerpt":46,"thumbnail_image":400,"tags":401},{"id":49},[51,52,53,54,55,56,57],{"id":403,"title":404,"slug":405,"excerpt":406,"thumbnail_image":407,"tags":409},"40","Menyelami Distributed Tracing: Melacak Jejak Request di Balik Keruwetan Microservices","menyelami-distributed-tracing-melacak-jejak-request-microservices","Satu klik Checkout di backend kalian bisa memicu puluhan network call antar-service, tapi pas ada yang lambat, service mana sebenernya yang salah? Log aja nggak cukup buat njawab itu. Yuk, kita bedah Distributed Tracing!",{"id":408},"1ace92fa-b89c-4cef-ab75-4e4cd67a089c",[51,410,411,412,130,55,413],"distributed-systems","observability","open-telemetry","tracing","\u003Cp>Tabel transaksi atau log aktivitas kalian udah nembus ratusan juta sampai miliaran \u003Cem>row\u003C/em>? Kalau iya, kita satu klub. 😅\u003C/p>\n\u003Cp>Awalnya, pas data masih ribuan \u003Cem>row\u003C/em>, semua \u003Cem>query\u003C/em> \u003Ccode>SELECT\u003C/code> jalan secepat kilat. Tapi begitu ukuran tabel membengkak sampai puluhan \u003Cem>gigabyte\u003C/em>, semuanya berubah:\u003C/p>\n\u003Cul>\n\u003Cli>\u003Cem>Index B-Tree\u003C/em> nggak muat lagi di \u003Cem>RAM\u003C/em> (\u003Cem>buffer pool\u003C/em>).\u003C/li>\n\u003Cli>Setiap \u003Ccode>INSERT\u003C/code> baru mulai kerasa lambat gara-gara proses \u003Cem>index balancing\u003C/em> yang berat.\u003C/li>\n\u003Cli>\u003Cem>Query\u003C/em> laporan bulanan bikin \u003Cem>CPU\u003C/em> database melonjak sampai 100% dan ngunci \u003Cem>row\u003C/em> lainnya.\u003C/li>\n\u003C/ul>\n\u003Cp>Pas teknik optimasi standar kayak \u003Cem>indexing\u003C/em> dan \u003Cem>connection pooling\u003C/em> udah nggak mempan lagi, langkah arsitektur berikutnya adalah mecah data.\u003C/p>\n\u003Cp>Nah, dua istilah yang paling sering muncul di sini adalah \u003Cem>Partitioning\u003C/em> dan \u003Cem>Sharding\u003C/em>. Kedengerannya mirip, sih, tapi arsitektur, tujuan, dan tingkat kerumitannya beda banget. Yuk, kita bedah satu-satu biar kalian nggak salah pilih.\u003C/p>\n\u003Ch2 id=\"ibaratnya-kayak-apa-sih\">Ibaratnya Kayak Apa, Sih?\u003C/h2>\n\u003Cp>Biar gampang, bayangin pengelolaan berkas dokumen kantor.\u003C/p>\n\u003Cp>\u003Cem>Table Partitioning\u003C/em> itu kayak satu lemari arsip besar yang dikasih sekat laci. Berkasnya udah menumpuk setinggi gunung, jadi kalian pasang sekat bertanda Laci 2024, Laci 2025, dan Laci 2026. Semua tetap di lemari fisik yang sama—\u003Cstrong>satu \u003Cem>server\u003C/em> database\u003C/strong>. Pas staf nyari surat Mei 2025, dia langsung buka Laci 2025 tanpa nyisir laci tahun lain. Proses instan inilah yang disebut \u003Cem>Partition Pruning\u003C/em>.\u003C/p>\n\u003Cp>\u003Cem>Database Sharding\u003C/em> itu beda cerita. Kalau lemarinya udah penuh sampai ruangan kantor nggak muat, kalian malah nyewa 3 gedung gudang terpisah: Jakarta, Surabaya, dan Medan. Berkas nasabah Jawa barat masuk Jakarta, Jawa timur masuk Surabaya, Sumatra masuk Medan. Datanya benar-benar tersebar di mesin fisik yang berbeda. Jadi, kalau gudang Jakarta kebanjiran, gudang Surabaya dan Medan tetap jalan normal.\u003C/p>\n\u003Ch2 id=\"sebenernya-apa-sih-table-partitioning-itu\">Sebenernya Apa Sih \u003Cem>Table Partitioning\u003C/em> Itu?\u003C/h2>\n\u003Cp>\u003Cem>Partitioning\u003C/em> itu fitur bawaan dari sistem manajemen database relasional modern kayak \u003Ca href=\"https://www.postgresql.org/docs/current/ddl-partitioning.html\">PostgreSQL\u003C/a> dan \u003Ca href=\"https://www.mysql.com/\">MySQL\u003C/a>.\u003C/p>\n\u003Cp>Secara logis, aplikasi tetap lihat datanya sebagai satu tabel utuh—misal \u003Ccode>orders\u003C/code>. Tapi secara fisik di level \u003Cem>disk\u003C/em>, database mecahnya jadi tabel-tabel partisi yang lebih kecil.\u003C/p>\n\u003Cp>Tipe \u003Cem>partitioning\u003C/em> yang populer ada tiga:\u003C/p>\n\u003Col>\n\u003Cli>\u003Cem>Range Partitioning\u003C/em>—mecah data berdasarkan rentang nilai, paling umum berdasarkan tanggal. Contohnya \u003Ccode>orders_2026_q1\u003C/code>, \u003Ccode>orders_2026_q2\u003C/code>.\u003C/li>\n\u003Cli>\u003Cem>List Partitioning\u003C/em>—mecah data berdasarkan daftar nilai diskret, misal kode negara: ID, SG, MY.\u003C/li>\n\u003Cli>\u003Cem>Hash Partitioning\u003C/em>—mecah data secara merata pakai fungsi \u003Cem>modulo hash\u003C/em> dari kolom kunci.\u003C/li>\n\u003C/ol>\n\u003Cp>Di PostgreSQL, deklarasi partisinya ngangenin banget:\u003C/p>\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\">SQL\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=\"--%201.%20Buat%20master%20table%20dengan%20partisi%20Range%20tanggal%0ACREATE%20TABLE%20orders%20(%0A%20%20%20%20order_id%20BIGSERIAL%2C%0A%20%20%20%20customer_id%20BIGINT%20NOT%20NULL%2C%0A%20%20%20%20order_date%20DATE%20NOT%20NULL%2C%0A%20%20%20%20total_amount%20NUMERIC(12%2C%202)%2C%0A%20%20%20%20status%20VARCHAR(20)%2C%0A%20%20%20%20PRIMARY%20KEY%20(order_id%2C%20order_date)%0A)%20PARTITION%20BY%20RANGE%20(order_date)%3B%0A%0A--%202.%20Buat%20partisi%20fisik%20untuk%20kuartal%201%20%26%202%20tahun%202026%0ACREATE%20TABLE%20orders_2026_q1%20PARTITION%20OF%20orders%0A%20%20%20%20FOR%20VALUES%20FROM%20('2026-01-01')%20TO%20('2026-04-01')%3B%0A%0ACREATE%20TABLE%20orders_2026_q2%20PARTITION%20OF%20orders%0A%20%20%20%20FOR%20VALUES%20FROM%20('2026-04-01')%20TO%20('2026-07-01')%3B\" 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\" tabindex=\"0\">\u003Ccode>\u003Cspan class=\"line\">\u003Cspan style=\"color:#6A737D\">-- 1. Buat master table dengan partisi Range tanggal\u003C/span>\u003C/span>\n\u003Cspan class=\"line\">\u003Cspan style=\"color:#F97583\">CREATE\u003C/span>\u003Cspan style=\"color:#F97583\"> TABLE\u003C/span>\u003Cspan style=\"color:#B392F0\"> orders\u003C/span>\u003Cspan style=\"color:#E1E4E8\"> (\u003C/span>\u003C/span>\n\u003Cspan class=\"line\">\u003Cspan style=\"color:#E1E4E8\">    order_id \u003C/span>\u003Cspan style=\"color:#F97583\">BIGSERIAL\u003C/span>\u003Cspan style=\"color:#E1E4E8\">,\u003C/span>\u003C/span>\n\u003Cspan class=\"line\">\u003Cspan style=\"color:#E1E4E8\">    customer_id \u003C/span>\u003Cspan style=\"color:#F97583\">BIGINT\u003C/span>\u003Cspan style=\"color:#F97583\"> NOT NULL\u003C/span>\u003Cspan style=\"color:#E1E4E8\">,\u003C/span>\u003C/span>\n\u003Cspan class=\"line\">\u003Cspan style=\"color:#E1E4E8\">    order_date \u003C/span>\u003Cspan style=\"color:#F97583\">DATE\u003C/span>\u003Cspan style=\"color:#F97583\"> NOT NULL\u003C/span>\u003Cspan style=\"color:#E1E4E8\">,\u003C/span>\u003C/span>\n\u003Cspan class=\"line\">\u003Cspan style=\"color:#E1E4E8\">    total_amount \u003C/span>\u003Cspan style=\"color:#F97583\">NUMERIC\u003C/span>\u003Cspan style=\"color:#E1E4E8\">(\u003C/span>\u003Cspan style=\"color:#79B8FF\">12\u003C/span>\u003Cspan style=\"color:#E1E4E8\">, \u003C/span>\u003Cspan style=\"color:#79B8FF\">2\u003C/span>\u003Cspan style=\"color:#E1E4E8\">),\u003C/span>\u003C/span>\n\u003Cspan class=\"line\">\u003Cspan style=\"color:#F97583\">    status\u003C/span>\u003Cspan style=\"color:#F97583\"> VARCHAR\u003C/span>\u003Cspan style=\"color:#E1E4E8\">(\u003C/span>\u003Cspan style=\"color:#79B8FF\">20\u003C/span>\u003Cspan style=\"color:#E1E4E8\">),\u003C/span>\u003C/span>\n\u003Cspan class=\"line\">\u003Cspan style=\"color:#F97583\">    PRIMARY KEY\u003C/span>\u003Cspan style=\"color:#E1E4E8\"> (order_id, order_date)\u003C/span>\u003C/span>\n\u003Cspan class=\"line\">\u003Cspan style=\"color:#E1E4E8\">) \u003C/span>\u003Cspan style=\"color:#F97583\">PARTITION\u003C/span>\u003Cspan style=\"color:#F97583\"> BY\u003C/span>\u003Cspan style=\"color:#F97583\"> RANGE\u003C/span>\u003Cspan style=\"color:#E1E4E8\"> (order_date);\u003C/span>\u003C/span>\n\u003Cspan class=\"line\">\u003C/span>\n\u003Cspan class=\"line\">\u003Cspan style=\"color:#6A737D\">-- 2. Buat partisi fisik untuk kuartal 1 & 2 tahun 2026\u003C/span>\u003C/span>\n\u003Cspan class=\"line\">\u003Cspan style=\"color:#F97583\">CREATE\u003C/span>\u003Cspan style=\"color:#F97583\"> TABLE\u003C/span>\u003Cspan style=\"color:#B392F0\"> orders_2026_q1\u003C/span>\u003Cspan style=\"color:#F97583\"> PARTITION\u003C/span>\u003Cspan style=\"color:#E1E4E8\"> OF orders\u003C/span>\u003C/span>\n\u003Cspan class=\"line\">\u003Cspan style=\"color:#F97583\">    FOR\u003C/span>\u003Cspan style=\"color:#F97583\"> VALUES\u003C/span>\u003Cspan style=\"color:#F97583\"> FROM\u003C/span>\u003Cspan style=\"color:#E1E4E8\"> (\u003C/span>\u003Cspan style=\"color:#9ECBFF\">'2026-01-01'\u003C/span>\u003Cspan style=\"color:#E1E4E8\">) \u003C/span>\u003Cspan style=\"color:#F97583\">TO\u003C/span>\u003Cspan style=\"color:#E1E4E8\"> (\u003C/span>\u003Cspan style=\"color:#9ECBFF\">'2026-04-01'\u003C/span>\u003Cspan style=\"color:#E1E4E8\">);\u003C/span>\u003C/span>\n\u003Cspan class=\"line\">\u003C/span>\n\u003Cspan class=\"line\">\u003Cspan style=\"color:#F97583\">CREATE\u003C/span>\u003Cspan style=\"color:#F97583\"> TABLE\u003C/span>\u003Cspan style=\"color:#B392F0\"> orders_2026_q2\u003C/span>\u003Cspan style=\"color:#F97583\"> PARTITION\u003C/span>\u003Cspan style=\"color:#E1E4E8\"> OF orders\u003C/span>\u003C/span>\n\u003Cspan class=\"line\">\u003Cspan style=\"color:#F97583\">    FOR\u003C/span>\u003Cspan style=\"color:#F97583\"> VALUES\u003C/span>\u003Cspan style=\"color:#F97583\"> FROM\u003C/span>\u003Cspan style=\"color:#E1E4E8\"> (\u003C/span>\u003Cspan style=\"color:#9ECBFF\">'2026-04-01'\u003C/span>\u003Cspan style=\"color:#E1E4E8\">) \u003C/span>\u003Cspan style=\"color:#F97583\">TO\u003C/span>\u003Cspan style=\"color:#E1E4E8\"> (\u003C/span>\u003Cspan style=\"color:#9ECBFF\">'2026-07-01'\u003C/span>\u003Cspan style=\"color:#E1E4E8\">);\u003C/span>\u003C/span>\u003C/code>\u003C/pre>\n  \u003C/div>\n\u003C/div>\u003Cp>Ketika aplikasi jalankan \u003Ccode>SELECT * FROM orders WHERE order_date = '2026-02-15'\u003C/code>, PostgreSQL otomatis cuma memindai \u003Ccode>orders_2026_q1\u003C/code> dan ngabaikan partisi lainnya. Itu \u003Cem>Partition Pruning\u003C/em> yang tadi kita singgung. 😎\u003C/p>\n\u003Cp>Oh iya, perhatiin kolom \u003Ccode>order_date\u003C/code> harus ikut jadi bagian \u003Cem>primary key\u003C/em>. Soalnya, PostgreSQL mewajibkan kolom partisi masuk ke \u003Cem>key\u003C/em> uniknya. Kalau nggak, \u003Ccode>CREATE TABLE\u003C/code>-nya bakal langsung ngamuk.\u003C/p>\n\u003Ch2 id=\"terus-database-sharding-itu-apa-bedaannya\">Terus, \u003Cem>Database Sharding\u003C/em> Itu Apa Bedaannya?\u003C/h2>\n\u003Cp>Kalau \u003Cem>Partitioning\u003C/em> mecah tabel di dalam satu \u003Cem>server\u003C/em>, \u003Cem>Sharding\u003C/em> justru ngedistribusikan data ke banyak \u003Cem>server\u003C/em> database mandiri yang disebut \u003Cem>shard\u003C/em>.\u003C/p>\n\u003Cp>Tiap \u003Cem>server shard\u003C/em> adalah \u003Cem>instance\u003C/em> database lengkap yang nyimpen subset data tertentu. Arsitektur ini \u003Cstrong>bentuk sejati dari \u003Cem>Horizontal Scaling\u003C/em>\u003C/strong> (\u003Cem>Scale-Out\u003C/em>).\u003C/p>\n\u003Cp>Kunci suksesnya adalah milih \u003Cem>sharding key\u003C/em> yang tepat buat memetakan data ke \u003Cem>shard\u003C/em> tujuan:\u003C/p>\n\u003Col>\n\u003Cli>\u003Cem>Hash-Based Sharding\u003C/em>—hitung nilai \u003Cem>hash\u003C/em> dari ID, misal \u003Ccode>hash(user_id) % jumlah_shard\u003C/code>. Distribusinya merata, tapi \u003Cem>range query\u003C/em> jadi susah. Buat nambah atau ngurangin jumlah \u003Cem>shard\u003C/em> tanpa bikin data berantakan, teknik \u003Cem>consistent hashing\u003C/em> sering dipakai.\u003C/li>\n\u003Cli>\u003Cem>Range-Based Sharding\u003C/em>—mecah berdasarkan rentang alfabet atau wilayah, misal \u003Cem>user\u003C/em> A–M di Shard 1 dan N–Z di Shard 2. Rentan bikin \u003Cem>Hotspot Shard\u003C/em> kalau satu kelompok data jauh lebih aktif.\u003C/li>\n\u003Cli>\u003Cem>Directory / Lookup-Based Sharding\u003C/em>—nyimpen tabel pemetaan terpusat (\u003Cem>lookup service\u003C/em>) yang nyatet ID mana ada di \u003Cem>shard\u003C/em> mana. Fleksibel banget, tapi tabel \u003Cem>lookup\u003C/em>-nya bisa jadi \u003Cem>single point of failure\u003C/em> dan \u003Cem>bottleneck\u003C/em> baru.\u003C/li>\n\u003C/ol>\n\u003Ch2 id=\"apa-aja-sih-susahnya-sharding\">Apa Aja Sih Susahnya \u003Cem>Sharding\u003C/em>?\u003C/h2>\n\u003Cp>\u003Cstrong>Jangan buru-buru \u003Cem>sharding\u003C/em>\u003C/strong> sebelum benar-benar kepepet, ya. Kerumitan arsitekturnya bukan main. 😅\u003C/p>\n\u003Cp>Pertama, kita kehilangan \u003Cem>Cross-Shard JOIN\u003C/em>. Tabel pelanggan di Shard A dan tabel transaksi di Shard B \u003Cstrong>nggak bisa lagi di-\u003Cem>JOIN\u003C/em> pakai SQL biasa\u003C/strong>. \u003Cem>Query\u003C/em>-nya harus digabung manual di level aplikasi backend (\u003Cem>Application-Level Join\u003C/em>).\u003C/p>\n\u003Cp>Kedua, muncul urusan transaksi terdistribusi. Menjamin prinsip ACID di beberapa \u003Cem>server\u003C/em> fisik butuh protokol \u003Cem>Two-Phase Commit\u003C/em> (2PC) atau \u003Cem>Saga Pattern\u003C/em> yang ribet dan lambat.\u003C/p>\n\u003Cp>Ketiga, ada \u003Cem>Re-Sharding\u003C/em>. Pas kapasitas 4 \u003Cem>shard\u003C/em> udah penuh dan kalian mau nambah jadi 8, memindahkan data lama antar \u003Cem>server\u003C/em> (\u003Cem>data rebalancing\u003C/em>) tanpa \u003Cem>downtime\u003C/em> itu pekerjaan yang bikin keringetan.\u003C/p>\n\u003Cp>Biar nggak bikin pusing sendiri, ekosistem cloud modern nyediain \u003Cem>middleware\u003C/em> terdistribusi kayak \u003Ca href=\"https://vitess.io/\">Vitess\u003C/a> buat MySQL skala raksasa, \u003Ca href=\"https://www.citusdata.com/\">Citus Data\u003C/a> buat PostgreSQL, atau database \u003Cem>NewSQL\u003C/em> kayak \u003Ca href=\"https://www.cockroachlabs.com/\">CockroachDB\u003C/a>.\u003C/p>\n\u003Ch2 id=\"kapan-pakai-partitioning-kapan-baru-sharding\">Kapan Pakai \u003Cem>Partitioning\u003C/em>, Kapan Baru \u003Cem>Sharding\u003C/em>?\u003C/h2>\n\u003Cp>Penskalaan database itu perjalanan bertahap, jadi \u003Cstrong>urutannya penting\u003C/strong>:\u003C/p>\n\u003Col>\n\u003Cli>Optimasi dulu yang murah: rapikan \u003Cem>query\u003C/em>, pasang \u003Cem>index\u003C/em> komposit, dan \u003Cem>cache\u003C/em> data panas (\u003Cem>hot data\u003C/em>) di Redis.\u003C/li>\n\u003Cli>Baru pakai \u003Cem>Table Partitioning\u003C/em> kalau data historis—log, \u003Cem>audit trail\u003C/em>, order lama—mulai menumpuk di satu \u003Cem>server\u003C/em>, dan kapasitas \u003Cem>disk\u003C/em> maupun \u003Cem>RAM\u003C/em>-nya masih cukup. Bonusnya, hapus data kedaluwarsa jadi cepet: \u003Ccode>DROP TABLE\u003C/code> partisi lama jauh lebih gesit ketimbang \u003Ccode>DELETE FROM ... WHERE date < ...\u003C/code>.\u003C/li>\n\u003Cli>\u003Cem>Database Sharding\u003C/em> cuma kalau volume data dan \u003Cem>write throughput\u003C/em> udah ngelewatin kapasitas mesin terbesar yang bisa disewa (\u003Cem>Vertical Scale Limit\u003C/em>), atau sistem butuh isolasi data per wilayah geografis (\u003Cem>data residency compliance\u003C/em>).\u003C/li>\n\u003C/ol>\n\u003Ch2 id=\"jadi-kapan-data-bener-bener-perlu-dipecah\">Jadi, Kapan Data Bener-bener Perlu Dipecah?\u003C/h2>\n\u003Cp>\u003Cem>Partitioning\u003C/em> itu langkah rapi buat ngatur tabel raksasa yang masih betah di satu mesin. Sedangkan \u003Cem>sharding\u003C/em> adalah \u003Cstrong>senjata pamungkas\u003C/strong>, dipakai pas satu \u003Cem>server\u003C/em> bener-bener udah nggak mampu lagi.\u003C/p>\n\u003Cp>Mulailah dari yang murah: optimasi \u003Cem>query\u003C/em>, \u003Cem>connection pool\u003C/em>, dan \u003Cem>caching\u003C/em>. Naik ke \u003Cem>partitioning\u003C/em> kalau dirasa perlu. Baru deh, pertimbangkan \u003Cem>sharding\u003C/em> kalau sistem udah menembus skala jutaan transaksi per detik di panggung global.\u003C/p>\n\u003Cp>Selamat ber-\u003Cem>scaling\u003C/em> ria, dan semoga data kalian tetap rapi tersimpan di laci-laci \u003Cem>shard\u003C/em>-nya! 👋\u003C/p>\n","\u003Cul>\n\u003Cli>\u003Cem>Table Partitioning\u003C/em> mecah tabel raksasa jadi partisi kecil di dalam satu \u003Cem>instance\u003C/em> database yang sama, biar \u003Cem>index\u003C/em> tetap enteng dan \u003Cem>query pruning\u003C/em> jalan.\u003C/li>\n\u003Cli>\u003Cem>Database Sharding\u003C/em> nyebarin data ke banyak \u003Cem>server\u003C/em> terpisah (\u003Cem>horizontal scaling\u003C/em>) pas kapasitas satu mesin udah mentok.\u003C/li>\n\u003Cli>Pemilihan \u003Cem>sharding key\u003C/em>—entah \u003Cem>range-based\u003C/em>, \u003Cem>hash-based\u003C/em>, atau \u003Cem>directory-based\u003C/em>—nentuin apakah beban terbagi rata atau malah bikin \u003Cem>hotspot\u003C/em>.\u003C/li>\n\u003Cli>Harga dari \u003Cem>sharding\u003C/em> itu mahal: \u003Cem>cross-shard join\u003C/em> hilang, transaksi terdistribusi butuh 2PC atau \u003Cem>Saga Pattern\u003C/em>, dan \u003Cem>re-sharding\u003C/em> jadi kerjaan yang bikin keringetan.\u003C/li>\n\u003C/ul>\n",[417,420,423,431],{"id":328,"title":329,"slug":330,"excerpt":331,"thumbnail_image":418,"tags":419},{"id":333},[335,336,337,338,339],{"id":86,"title":87,"slug":88,"excerpt":89,"thumbnail_image":421,"tags":422},{"id":91},[51,54,93,94,95,55,96],{"id":424,"title":425,"slug":426,"excerpt":427,"thumbnail_image":428,"tags":430},"44","Transactional Outbox Pattern: Solusi Konsistensi Database dan Message Broker Tanpa 2PC","transactional-outbox-pattern-konsistensi-database-message-broker","Pernah nggak kalian lihat pesanan udah masuk database, tapi email konfirmasinya nggak pernah kekirim? Itu gejala *dual-write problem*. Yuk, kita bedah Transactional Outbox Pattern biar data dan *event* kalian nggak lagi berselisih paham!",{"id":429},"e3c617fd-1486-4b82-b937-94fbec846c77",[51,130,55,52,129,54,53],{"id":432,"title":433,"slug":434,"excerpt":435,"thumbnail_image":436,"tags":438},"43","Dead Letter Queue (DLQ) & Retry Policy: Menyelamatkan Pesan Nyasar di RabbitMQ Tanpa Bikin Worker Macet","dead-letter-queue-retry-policy-rabbitmq-resilient-messaging","Pernah nggak sih, *worker* kalian nolak satu pesan terus-terusan sampai CPU melonjak 100%? Itu namanya *poison message loop*, jebakan klasik di RabbitMQ. Yuk, kita bahas cara pasang *retry policy* dan *dead letter queue* yang bener!",{"id":437},"6c0a7ead-4841-4073-b29e-df7ae0f2aa3c",[128,129,51,55,130,131,287],[440,444,447,450,453,456],{"text":441,"depth":442,"id":443},"Ibaratnya Kayak Apa, Sih?",2,"ibaratnya-kayak-apa-sih",{"text":445,"depth":442,"id":446},"Sebenernya Apa Sih Table Partitioning Itu?","sebenernya-apa-sih-table-partitioning-itu",{"text":448,"depth":442,"id":449},"Terus, Database Sharding Itu Apa Bedaannya?","terus-database-sharding-itu-apa-bedaannya",{"text":451,"depth":442,"id":452},"Apa Aja Sih Susahnya Sharding?","apa-aja-sih-susahnya-sharding",{"text":454,"depth":442,"id":455},"Kapan Pakai Partitioning, Kapan Baru Sharding?","kapan-pakai-partitioning-kapan-baru-sharding",{"text":457,"depth":442,"id":458},"Jadi, Kapan Data Bener-bener Perlu Dipecah?","jadi-kapan-data-bener-bener-perlu-dipecah",1791045070906]