UUID Dijelaskan: Struktur 128-Bit, Versi & Kasus Penggunaan Dunia Nyata

Setiap kali Anda mendaftar layanan, identifier unik dibuat untuk akun Anda. Setiap permintaan API membawa trace ID. Setiap baris di database terdistribusi memerlukan primary key yang tidak akan bertabrakan dengan key yang dihasilkan di mesin lain. Solusi di balik semua ini? UUID — Universally Unique Identifier.

Artikel ini menjelaskan apa itu UUID, bagaimana strukturnya, apa yang dilakukan setiap versi, dan kapan harus menggunakan (atau menghindari) mereka.

UUID Sekilas

UUID adalah identifier 128-bit (16-byte) yang dirancang untuk unik secara global tanpa memerlukan otoritas pusat. Ditulis sebagai 32 digit heksadesimal dalam format kanonikal 8-4-4-4-12:

550e8400-e29b-41d4-a716-446655440000
|------| |--| |--| |--| |----------|
 8 hex   4    4    4      12 hex

Itu 32 karakter hex + 4 tanda hubung = total 36 karakter. Tanda hubung murni kosmetik — tidak membawa data.

Fakta penting:

128 bit = 2¹²⁸ ≈ 3,4 × 10³⁸ nilai yang mungkin
Distandarisasi oleh RFC 9562 (Mei 2024, menggantikan RFC 4122)
Juga disebut GUID (Globally Unique Identifier) di ekosistem Microsoft — format sama, nama berbeda
Didukung secara native oleh PostgreSQL (tipe uuid), MySQL (BINARY(16) atau CHAR(36)), dan hampir setiap bahasa pemrograman

Anatomi UUID

Setiap UUID mengenkode dua field metadata di posisi bit tetap, terlepas dari versi:

550e8400-e29b-41d4-a716-446655440000
                  ^  ^
                  |  |
          Version-┘  └-Variant

Field Version (Bit 48–51)

Digit hex ke-13 (digit pertama grup ketiga) mengidentifikasi versi UUID:

Digit Hex	Versi	Metode
`1`	v1	Timestamp + alamat MAC
`3`	v3	Hash MD5 dari namespace + name
`4`	v4	Acak secara kriptografis
`5`	v5	Hash SHA-1 dari namespace + name
`6`	v6	Timestamp yang diurutkan ulang (RFC 9562)
`7`	v7	Timestamp Unix + acak (RFC 9562)
`8`	v8	Kustom / spesifik implementasi

Field Variant (Bit 64–65)

Digit hex ke-17 (digit pertama grup keempat) mengidentifikasi variant. Untuk UUID RFC 4122/9562, bit pertama adalah 10, yang berarti digit hex ini selalu 8, 9, a, atau b.

Contoh Pemecahan

550e8400-e29b-41d4-a716-446655440000
              ↑         ↑
              4 → v4    a → variant RFC 4122

Ini adalah UUID v4 (acak), variant RFC 4122/9562.

Versi UUID Dijelaskan

Versi 1: Timestamp + Alamat MAC

UUID v1 adalah desain asli. Mengenkode:

Timestamp 60-bit — interval 100-nanodetik sejak 15 Oktober 1582 (reformasi kalender Gregorian)
Clock sequence 14-bit — penghitung monotonisitas untuk mencegah duplikat saat rollback jam
Node 48-bit — biasanya alamat MAC mesin

|        Timestamp         | Ver |  Clk  |Var|    Node (MAC)     |
| 60 bit                   | 4b  | 14b   |2b | 48 bit            |

Masalah:

Mengekspos waktu pembuatan dan identitas hardware (risiko privasi)
Alamat MAC bisa dipalsukan, merusak keunikan
Epoch 1582 membingungkan dan memerlukan konversi

Verdict: Deprecated oleh RFC 9562. Gunakan v7 untuk UUID berbasis waktu.

Versi 3: Berbasis Nama MD5 (Deterministik)

UUID v3 melakukan hash namespace UUID dan string name menggunakan MD5. Input yang sama selalu menghasilkan UUID yang sama.

import uuid
# namespace = DNS, name = "example.com"
print(uuid.uuid3(uuid.NAMESPACE_DNS, "example.com"))
# → "9073926b-929f-31c2-abc9-fad77ae3e8eb"  (selalu nilai ini)

Empat namespace standar didefinisikan:

DNS: 6ba7b810-9dad-11d1-80b4-00c04fd430c8
URL: 6ba7b811-9dad-11d1-80b4-00c04fd430c8
OID: 6ba7b812-9dad-11d1-80b4-00c04fd430c8
X.500: 6ba7b814-9dad-11d1-80b4-00c04fd430c8

Verdict: Fungsional tapi lebih baik pilih v5 — SHA-1 lebih kuat dari MD5.

Versi 4: Acak — Yang Paling Populer

UUID v4 mengisi 122 bit dengan data acak yang aman secara kriptografis (6 bit sisanya dicadangkan untuk field version dan variant).

|           Acak            | Ver |    Acak        |Var|    Acak          |
| 48 bit                    | 4b  | 12 bit         |2b | 62 bit           |

Dengan 2¹²² ≈ 5,3 × 10³⁶ nilai yang mungkin, probabilitas collision sangat rendah secara astronomis. Untuk mencapai peluang 50% setidaknya satu collision, Anda memerlukan kira-kira 2,71 × 10¹⁸ UUID — itu 2,71 kuintiliun.

// Setiap browser modern dan Node.js mendukung ini
const id = crypto.randomUUID();
console.log(id); // → "9b1deb4d-3b7d-4bad-9bdd-2b0d7b3dcb6d"

Kelebihan: sederhana, privat, didukung universal, tidak perlu koordinasi.

Kelemahan: distribusi acak menyebabkan fragmentasi index B-tree saat digunakan sebagai primary key database. Untuk kasus penggunaan database-heavy, pertimbangkan v7.

Versi 5: Berbasis Nama SHA-1 (Deterministik)

Identik dengan v3 tapi menggunakan SHA-1 daripada MD5. Input yang sama selalu menghasilkan UUID yang sama.

import uuid
print(uuid.uuid5(uuid.NAMESPACE_DNS, "example.com"))
# → "cfbff0d1-9375-5685-968c-48ce8b15ae17"  (selalu nilai ini)

Kasus penggunaan:

Menghasilkan ID stabil dari URL atau nama DNS
Key content-addressable storage
Fixture pengujian yang dapat direproduksi

Penting: v3 dan v5 TIDAK dimaksudkan untuk keamanan. Mereka deterministik — siapa pun yang mengetahui namespace dan name bisa mereproduksi UUID-nya.

Versi 7: Timestamp Unix + Acak (Direkomendasikan untuk Proyek Baru)

UUID v7 adalah versi terbaru, diperkenalkan di RFC 9562 (Mei 2024). Mengenkode:

Timestamp Unix 48-bit dalam milidetik — meningkat secara monotonik
74 bit keacakan kriptografis

|    Timestamp Unix (ms)    | Ver |  rand_a  |Var|     rand_b       |
| 48 bit                    | 4b  | 12 bit   |2b | 62 bit           |

Ini berarti UUID v7 secara alami terurut berdasarkan waktu pembuatan — UUID yang lebih baru selalu lebih besar secara leksikografis dari yang lebih lama. Properti ini membuatnya ideal untuk primary key database, di mana index B-tree tetap sekuensial daripada terfragmentasi secara acak.

import { v7 as uuidv7 } from "uuid";

const id1 = uuidv7(); // dihasilkan pada T₁
const id2 = uuidv7(); // dihasilkan pada T₂ (T₂ > T₁)
console.log(id1 < id2); // → true (perbandingan leksikografis)

Mengapa ini penting untuk database: properti sekuensial v7 mengurangi page split index hingga 90% dibanding v4, menghasilkan insert lebih cepat, index lebih kecil, dan performa cache yang lebih baik.

UUID vs GUID — Apa Perbedaannya?

Tidak ada perbedaan fungsional. GUID (Globally Unique Identifier) adalah nama Microsoft untuk UUID, digunakan di Windows, .NET, COM, dan SQL Server. Formatnya identik: 128 bit, hex 8-4-4-4-12.

Satu-satunya perbedaan kosmetik: tool Microsoft terkadang menampilkan GUID dalam huruf besar dengan kurung kurawal:

UUID: 550e8400-e29b-41d4-a716-446655440000
GUID: {550E8400-E29B-41D4-A716-446655440000}

Jika seseorang bertanya tentang “perbedaan UUID dan GUID,” jawabannya adalah: branding.

Nilai UUID Khusus

RFC 9562 mendefinisikan dua UUID khusus:

Nama	Nilai	Tujuan
Nil UUID	`00000000-0000-0000-0000-000000000000`	Merepresentasikan ketiadaan nilai (seperti `null`)
Max UUID	`ffffffff-ffff-ffff-ffff-ffffffffffff`	Penanda batas atau nilai sentinel

Jangan pernah gunakan ini sebagai identifier aktual — mereka tidak unik secara definisi.

Probabilitas Collision: Masalah Ulang Tahun

“Masalah ulang tahun” menghitung berapa banyak UUID yang diperlukan sebelum collision menjadi mungkin. Untuk UUID v4 (122 bit acak):

UUID yang Dihasilkan	Probabilitas Collision
1 juta	~10⁻²² (hampir mustahil)
1 miliar	~10⁻¹⁶ (masih bisa diabaikan)
2,71 × 10¹⁸	50% (batas “ulang tahun”)

Untuk konteks: jika Anda menghasilkan 1 miliar UUID per detik, akan memakan waktu 86 tahun untuk mencapai peluang 50% dari satu collision. Dalam praktiknya, kegagalan hardware, bug software, dan sinar kosmik semua lebih mungkin menyebabkan duplikat daripada matematika UUID v4.

Rumusnya: p(n) ≈ n² / (2 × 2¹²²)

Cara Memvalidasi UUID

UUID yang valid cocok dengan pola regex ini (case-insensitive):

^[0-9a-f]{8}-[0-9a-f]{4}-[1-7][0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$

Ini memeriksa:

Format hex 8-4-4-4-12
Digit version adalah 1–7 (posisi 15)
Nibble variant dimulai dengan 8, 9, a, atau b (posisi 20)

function isValidUUID(str) {
  return /^[0-9a-f]{8}-[0-9a-f]{4}-[1-7][0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$/i.test(str);
}

isValidUUID("550e8400-e29b-41d4-a716-446655440000"); // → true
isValidUUID("not-a-uuid"); // → false

Menghasilkan UUID di Setiap Bahasa

JavaScript / TypeScript

// Browser & Node.js — v4 bawaan
crypto.randomUUID();

// paket npm uuid — mendukung v1, v3, v4, v5, v7
import { v4, v7 } from "uuid";
v4(); // acak
v7(); // terurut waktu

Python

import uuid

uuid.uuid4()                                    # acak
uuid.uuid5(uuid.NAMESPACE_DNS, "example.com")   # deterministik
# uuid.uuid7() direncanakan untuk Python 3.14+

Go

import "github.com/google/uuid"

uuid.New()              // v4 acak
uuid.Must(uuid.NewV7()) // v7 terurut waktu

Java

import java.util.UUID;

UUID.randomUUID();        // v4 acak
// UUID v7: gunakan com.fasterxml.uuid atau java.util.UUID di JDK 21+

SQL (PostgreSQL)

-- v4 (PostgreSQL 13+)
SELECT gen_random_uuid();

-- v7 (PostgreSQL 18+)
SELECT uuidv7();

Kasus Penggunaan Umum

Primary Key Database

UUID memungkinkan Anda menghasilkan ID di mana saja — di aplikasi, di client, di edge — tanpa round trip database. Ini memungkinkan arsitektur offline-first dan menyederhanakan sistem terdistribusi. Gunakan v7 untuk performa index terbaik, atau v4 jika Anda tidak peduli dengan pengurutan.

API Request Tracing

Tetapkan UUID ke setiap permintaan API di titik masuk (gateway, load balancer). Teruskan melalui semua downstream service dalam header seperti X-Request-ID. Ini memudahkan korelasi log lintas microservice.

Idempotency Key

API menggunakan UUID sebagai idempotency key untuk memastikan permintaan yang dicoba ulang tidak membuat resource duplikat. Client menghasilkan UUID sebelum percobaan pertama dan mengirim UUID yang sama saat retry.

Session Identifier

UUID memberikan keunikan yang cukup untuk mencegah collision sesi di basis pengguna yang besar. Berbeda dengan integer auto-increment, mereka tidak bisa dienumerasi — penyerang tidak bisa menebak session ID valid dengan menaikkan angka.

Content-Addressable Storage

UUID v5 menghasilkan ID deterministik dari konten. Dengan input yang sama, Anda selalu mendapat UUID yang sama — berguna untuk deduplikasi, caching, dan build yang dapat direproduksi.

Pertimbangan Keamanan

UUID BUKAN Token Keamanan

UUID dirancang untuk keunikan, bukan kerahasiaan. Isu utama:

UUID v1 membocorkan timestamp pembuatan dan alamat MAC
UUID v4 memiliki 122 bit acak tapi struktur yang dapat diprediksi (bit version/variant tetap)
UUID v3/v5 deterministik — siapa pun yang mengetahui namespace dan name bisa mereproduksi UUID-nya

Untuk token keamanan, API key, atau secret sesi, gunakan CSPRNG khusus dengan 128+ bit keacakan murni:

// Untuk token keamanan — BUKAN UUID, tapi sepenuhnya acak
const token = Array.from(crypto.getRandomValues(new Uint8Array(32)))
  .map(b => b.toString(16).padStart(2, "0"))
  .join("");

UUID v7 Mengekspos Waktu Pembuatan

48 bit pertama UUID v7 mengenkode timestamp pembuatan dalam milidetik. Siapa pun yang menerima UUID v7 dapat mengekstrak kapan ia dibuat:

const hex = "01906b5e-4a3e-7234-8f56-b8c12d4e5678".replace(/-/g, "").slice(0, 12);
new Date(parseInt(hex, 16));
// → 2024-07-01T12:34:56.000Z

Jika waktu pembuatan adalah informasi sensitif, gunakan v4 sebagai gantinya.

Jangan Gunakan UUID untuk Mencegah Enumerasi

Meskipun UUID lebih sulit ditebak daripada integer sekuensial, mereka tidak boleh menjadi satu-satunya mekanisme kontrol akses Anda. Selalu terapkan pemeriksaan otorisasi — jangan mengandalkan kesamaran URL.

Pertanyaan yang Sering Diajukan

Mengapa ada tanda hubung di UUID?

Tanda hubung dalam format 8-4-4-4-12 murni untuk keterbacaan manusia. Mereka tidak membawa data dan diabaikan saat parsing. Beberapa sistem menyimpan UUID tanpa tanda hubung (32 karakter hex), yang sama validnya.

Bisakah dua UUID pernah sama?

Secara teoretis ya, secara praktis tidak. Untuk UUID v4 dengan 122 bit acak, probabilitas menghasilkan dua UUID identik kira-kira 1 banding 5,3 × 10³⁶ untuk pasangan mana pun. Pada tingkat pembuatan dunia nyata, Anda lebih mungkin disambar petir sambil memenangkan lotre daripada menemui collision UUID.

Apakah UUID sekuensial?

Hanya beberapa versi. UUID v1, v6, dan v7 mengandung timestamp dan terurut kronologis. UUID v4 sepenuhnya acak tanpa pengurutan. UUID v3 dan v5 deterministik tapi tidak terurut.

Berapa banyak penyimpanan yang digunakan UUID?

Binary: 16 byte (128 bit) — penyimpanan paling efisien
String (dengan tanda hubung): 36 byte (ASCII)
String (tanpa tanda hubung): 32 byte (ASCII)

Sebagian besar database menyimpan UUID dalam format binary secara internal. Tipe uuid native PostgreSQL menggunakan tepat 16 byte.

Haruskah saya menggunakan UUID atau auto-increment untuk primary key?

Auto-increment lebih sederhana untuk aplikasi single-database (lebih kecil, lebih cepat, sekuensial). UUID lebih baik untuk sistem terdistribusi (buat di mana saja, tanpa koordinasi, aman saat merge). Jika menggunakan UUID, pilih v7 untuk performa database terbaik.

Apa itu RFC 9562?

RFC 9562, diterbitkan Mei 2024, adalah standar UUID terbaru. Menggantikan RFC 4122 dan secara resmi memperkenalkan UUID versi 6, 7, dan 8. Mendeprecate v1 demi v6/v7 dan mendefinisikan nilai nil dan max UUID. Jika Anda mengimplementasikan pembuatan atau validasi UUID, RFC 9562 adalah referensi otoritatif.

Bisakah saya menggunakan UUID lintas bahasa pemrograman yang berbeda?

Ya. Format UUID (128-bit, hex 8-4-4-4-12) bersifat agnostik bahasa. UUID yang dihasilkan di JavaScript akan diparse dengan benar di Python, Go, Java, atau bahasa lain dengan dukungan UUID. Interoperabilitas ini adalah salah satu kekuatan terbesar UUID.

Hasilkan, decode, dan validasi UUID secara instan dengan UUID Generator kami — mendukung v1, v4, v5, dan v7 dengan pembuatan batch, 100% di browser Anda.

Memilih antara versi UUID untuk proyek berikutnya? Baca perbandingan UUID v4 vs v7 vs ULID vs Snowflake kami untuk panduan pemilihan praktis dengan benchmark database dan contoh kode.