Generator UUID

Apa Itu UUID dan Bagaimana Cara Pembuatannya Secara Offline?

UUID (Universally Unique Identifier) adalah label 128-bit yang dapat dibuat sepenuhnya secara offline, di dalam browser Anda, tanpa menghubungi server atau database pusat mana pun. Karena kemungkinan matematis dari dua UUID yang bertabrakan sangat rendah secara astronomis, pembuatan offline ini aman — dan menjadi fondasi arsitektur aplikasi local-first yang berfokus pada privasi.

Setiap kali Anda membuat akun pengguna baru, menyimpan dokumen, atau membuat tautan berbagi yang unik, ada kemungkinan besar seorang pengembang telah menetapkan UUID untuk tindakan tersebut.

Selama bertahun-tahun, pendekatan standar untuk menghasilkan pengidentifikasi unik adalah meminta database pusat untuk melakukannya. Anda mengirim permintaan ke server, database menambahkan angka (seperti ID #1042), dan mengirimkannya kembali. Ini adalah sistem yang andal, tetapi pada dasarnya membutuhkan koneksi konstan ke otoritas pusat.

Saat kita membangun aplikasi terdesentralisasi, perangkat lunak berbasis lokal (local-first), atau utilitas yang berfokus pada privasi, koneksi server yang konstan itu menjadi beban. Anda tidak dapat mengandalkan database untuk memberi tahu ID berikutnya jika aplikasi Anda harus berfungsi dengan sempurna secara offline.

Di sinilah UUID mengubah arsitektur. Anda dapat menghasilkan UUID secara lokal, sepenuhnya offline, tepat di dalam browser Anda, dan secara matematis menjamin bahwa ID tersebut tidak akan bertabrakan dengan ID lain yang pernah dibuat oleh orang lain.

Seperti Apa Tampilan UUID?

UUID adalah label 128-bit yang muncul sebagai string 36 karakter yang terdiri dari huruf, angka, dan tanda hubung.

123e4567-e89b-12d3-a456-426614174000

Kelihatannya seperti karakter acak, tetapi ada struktur yang ketat. String tersebut dibagi menjadi lima kelompok yang dipisahkan oleh tanda hubung (8-4-4-4-12). Meskipun ada beberapa versi UUID, Versi 4 (UUIDv4) adalah yang paling umum untuk pembuatan acak secara offline sepenuhnya.

Dalam UUIDv4, beberapa bit dicadangkan untuk menunjukkan versi dan varian. Itu menyisakan tepat 122 bit untuk keacakan murni.

Mengapa Dua UUID Tidak Pernah Sama?

Jika ribuan perangkat berbeda menghasilkan UUID secara offline, bagaimana tidak ada yang menghasilkan duplikat?

Jawabannya adalah skala.

Karena kita memiliki 122 bit acak, total jumlah kombinasi UUIDv4 yang mungkin adalah 2¹²².

Sebagai gambaran:

2¹²² ≈ 5.3 × 10³⁶

Itu adalah 5.3 undecillion kemungkinan ID.

Jika Anda menghasilkan 1 miliar UUID setiap detik selama 85 tahun ke depan, kemungkinan menghasilkan satu duplikat (tabrakan/collision) masih sekitar 50%. Karena kemungkinan tabrakan sangat rendah secara astronomis, kita dapat sepenuhnya menghilangkan pemeriksaan database. Browser Anda tidak perlu bertanya ke server "Apakah ID ini sudah digunakan?" — ia bisa langsung menghasilkan string dan berasumsi, dengan kepastian matematis yang hampir absolut, bahwa ID tersebut unik secara global. Inilah landasan arsitektur aplikasi offline-first.

Catatan Pengembang: Jebakan Pseudo-Random

Membangun generator UUID lokal terdengar sangat sederhana — hanya teks acak, bukan? Saat pertama kali membuat prototipe generator UUID offline untuk LokalTools, saya terjebak dalam masalah klasik JavaScript.

Untuk menghasilkan bit acak, saya menggunakan fungsi bawaan Math.random(). Fungsi tersebut cepat, sederhana, dan hasilnya terlihat sangat unik bagi mata manusia.

Masalahnya: Math.random() tidak benar-benar acak. Ini adalah Generator Angka Pseudo-Acak (PRNG). Browser mengimplementasikan ini menggunakan algoritma (seperti xorshift128+) yang dirancang untuk kecepatan, bukan untuk keamanan atau entropi kriptografis. Jika Anda menggunakan Math.random() untuk menghasilkan UUID dalam loop yang rapat, "benih" acak akan mulai tumpang tindih.

Dalam pengujian kami, saat menjalankan uji stres dengan menghasilkan 100.000 UUID secara lokal menggunakan Math.random(), kami mulai melihat adanya tabrakan. Matematika 5.3 undecillion akan runtuh jika generator angka acak Anda dapat diprediksi.

Solusinya: Kami harus membuang fungsi matematika standar dan menggunakan Web Crypto API. Secara khusus, kami mengubah mesin pembuatan kami untuk menggunakan window.crypto.getRandomValues().

Tidak seperti fungsi matematika JavaScript standar, Web Crypto API terhubung langsung ke sumber entropi sistem operasi Anda. Ia melihat variasi mikroskopis pada perangkat keras Anda — seperti kebisingan termal CPU atau waktu penekanan tombol — untuk memberi benih pada generator.

Dengan mendorong beban kerja ke API kriptografis tingkat OS, kami menjamin bahwa pembuatan di browser lokal mempertahankan keacakan entropi tinggi yang sebenarnya. Matematika kembali aman, dan semua tetap di sisi klien.

Mengapa Pembuatan Lokal Unggul dalam Privasi?

Arsitektur tradisional mengirimkan permintaan jaringan untuk menghasilkan atau memvalidasi ID sesi, token dokumen, atau kunci API. Alurnya seperti ini:

1. Perangkat Anda memanggil server.
2. Server menghasilkan UUID.
3. Server mencatat pembuatan tersebut dalam database.
4. UUID dikirimkan kembali ke perangkat Anda.

Pendekatan ini menciptakan latensi jaringan yang tidak perlu dan meninggalkan jejak audit di server pihak ketiga. Jika Anda menghasilkan kunci enkripsi unik untuk dokumen lokal yang aman, menghubungi server jarak jauh justru akan merusak tujuan privasi tersebut.

Dengan menghasilkan UUID secara lokal menggunakan mesin kripto browser, nol byte yang dikirimkan. ID tersebut hanya ada di RAM sistem lokal Anda sampai Anda memutuskan apa yang akan dilakukan dengannya. Dalam praktiknya, ini berarti pembuatan data Anda seprivat mungkin.

Kapan Database Menjadi Pemenang?

Pembuatan di sisi klien sangat tangguh, tetapi bukan solusi sempurna untuk setiap masalah rekayasa perangkat lunak. Anda harus menyadari pertimbangan arsitekturalnya.

Kenyataannya: UUID yang sepenuhnya acak sangat buruk untuk performa database.

Jika Anda membangun aplikasi yang perlu memasukkan jutaan baris ke dalam database relasional tradisional (seperti PostgreSQL atau MySQL), menggunakan UUIDv4 sebagai kunci utama (primary key) dapat menyebabkan masalah yang disebut "fragmentasi indeks."

Database relasional menggunakan struktur B-tree untuk mengatur data. Mereka lebih suka data dimasukkan dalam urutan berurutan (1, 2, 3, 4...). Karena UUIDv4 sepenuhnya acak, database harus terus-menerus membagi dan mengatur ulang pohon penyimpanan internalnya untuk menyesuaikan catatan baru. Hal ini menciptakan amplifikasi baca/tulis yang masif dan memperlambat kueri seiring berjalannya waktu.

Untuk database berperforma tinggi, integer auto-increment tradisional atau UUID yang diurutkan berdasarkan waktu (seperti UUIDv7, yang menempatkan stempel waktu di bagian awal string) secara fundamental lebih baik.

Namun untuk ID sesi, pembuatan dokumen offline, permintaan API idempoten, atau membangun alat pribadi berbasis lokal tanpa bergantung pada koneksi internet, pembuatan UUID lokal tetap tidak tertandingi.

Coba Sendiri

Berhentilah menghubungi server hanya untuk mendapatkan string teks yang unik. Jaga agar arsitektur aplikasi Anda tetap terpisah (decoupled) dan data Anda tetap privat.

Kunjungi Generator UUID LokalTools dan hasilkan ribuan pengidentifikasi yang aman secara kriptografis secara instan. Lihat seberapa cepat mesin Anda sendiri dapat menciptakan keacakan sejati, tepat di dalam browser Anda, tanpa satu pun permintaan yang menyentuh backend kami.

---

Pertanyaan yang Sering Diajukan

Apa itu UUID? UUID (Universally Unique Identifier) adalah pengidentifikasi 128-bit yang distandarisasi dalam RFC 4122, biasanya ditampilkan sebagai string 36 karakter yang dipisahkan oleh tanda hubung. UUID dirancang untuk bersifat unik secara global tanpa memerlukan otoritas pusat untuk menetapkannya.

Apa perbedaan antara UUID dan GUID? GUID (Globally Unique Identifier) adalah nama yang digunakan Microsoft untuk konsep yang sama. GUID dan UUID secara fungsional identik — keduanya adalah pengidentifikasi 128-bit yang mengikuti standar RFC 4122 yang sama. Kedua istilah tersebut dapat digunakan secara bergantian dalam kebanyakan konteks.

Bisakah dua UUID pernah sama? Secara matematis, ya — tetapi kemungkinannya sangat rendah sehingga dianggap praktis tidak mungkin. Dengan 2¹²² kombinasi UUIDv4 yang mungkin, Anda perlu menghasilkan lebih dari satu miliar UUID per detik selama beberapa dekade sebelum tabrakan menjadi kemungkinan yang signifikan secara statistik.

Apakah aman membuat UUID di browser tanpa server? Ya, selama Anda menggunakan window.crypto.getRandomValues() bukan Math.random(). Web Crypto API mengambil entropi dari sistem operasi Anda, sehingga UUID yang dihasilkan di browser aman secara kriptografis untuk digunakan sebagai token sesi, ID dokumen, dan kunci API.

Apa perbedaan UUIDv4 dan UUIDv7? UUIDv4 sepenuhnya acak (122 bit acak) dan paling baik untuk pembuatan offline di mana Anda membutuhkan privasi tanpa pengurutan berurutan. UUIDv7 menyematkan stempel waktu milidetik di bagian awal, sehingga dapat diurutkan dan jauh lebih efisien sebagai kunci utama database dalam beban kerja dengan banyak penyisipan.

Mengapa Math.random() buruk untuk menghasilkan UUID? Math.random() adalah generator angka pseudo-acak (PRNG) yang dioptimalkan untuk kecepatan, bukan keamanan kriptografis. Dalam pengujian stres, kami menemukan bahwa menghasilkan batch UUID yang besar dengan Math.random() menghasilkan tabrakan karena ruang seed yang mendasarinya terbatas. Selalu gunakan Web Crypto API untuk pembuatan UUID.

Kapan saya harus menggunakan UUID daripada integer auto-increment? Gunakan UUID ketika Anda perlu menghasilkan ID secara offline, di beberapa klien yang terputus, atau ketika Anda tidak ingin mengekspos jumlah rekaman berurutan kepada pengguna akhir. Gunakan integer auto-increment ketika Anda membutuhkan performa penyisipan database yang optimal dalam satu sistem terpusat.