UUID Oluşturucu (v4): RFC 4122 Standartları ve Entropi Matematiği
Dağıtık mimarilerde (Microservices) veya yüksek trafikli NoSQL veritabanlarında, geleneksel AUTO_INCREMENT (1, 2, 3...) ID'leri kullanmak sistemin ölçeklenmesini (Scalability) imkansız hale getirir. İki farklı sunucunun aynı anda "ID 45" değerini oluşturup çakışmasını (Collision) engellemek için, merkezi bir koordinasyona ihtiyaç duymayan UUID (Universally Unique Identifier) mimarisi geliştirilmiştir. Geliştirdiğimiz bu UUID v4 Oluşturucu, IETF'nin resmi RFC 4122 standartlarına uygun olarak, kriptografik seviyede güvenli (CSPRNG) rastgele (Random) 128-bit tanımlayıcılar üretir.
Microsoft dünyasında GUID olarak da bilinen bu 36 karakterlik (32 hex rakamı ve 4 tire) dizeler, xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx formatında oluşturulur. Formattaki "4" rakamı versiyon 4'ü temsil ederken, "y" rakamı ise her zaman 8, 9, A veya B olmak zorundadır. Bu kurallara uymayan sahte UUID'ler, veritabanı "Primary Key" (Birincil Anahtar) indekslemelerinde ölümcül performans hatalarına yol açar.
UUID v4 Çarpışma (Collision) Olasılığı Nedir?
Yazılımcıların en büyük korkusu "Ya iki kez aynı UUID üretilirse?" sorusudur. Matematiksel olarak UUID v4'ün 122 bitlik bir entropisi (Rastgelelik havuzu) vardır. Bu da evrende 5.3 × 10^36 farklı varyasyon olduğu anlamına gelir (2^122).
- Matematiksel Kanıt: Eğer saniyede 1 Milyar adet UUID v4 üretirseniz ve bunu 85 Yıl boyunca hiç durmadan yapmaya devam ederseniz, sadece tek bir çakışma (Collision) olma ihtimali %50'dir.
- Güvenlik: Sadece
Math.random()kullanan amatör araçlar donanım saati bazlı olduğu için tahmin edilebilir sonuçlar üretir (Pseudo-random). Bizim aracımız ise tarayıcının nativeCrypto.getRandomValues()API'sini kullanarak donanım seviyesinde entropi toplar ve %100 "Tahmin Edilemez" ID'ler sağlar.
Mimari (Architecture) Kararları: Ne Zaman Kullanılmalı?
UUID kullanmak her zaman en iyi çözüm değildir. Sistemin mimarisine göre avantaj ve dezavantajları iyi tartılmalıdır:
✅ Doğru Kullanım Alanları
Dağıtık sistemler (Örn: Birden fazla Node.js sunucusunun aynı veritabanına yazması), Offline-first (Önce çevrimdışı) çalışan mobil uygulamaların veri eşitlemesi ve URL rotalarında ID gizleme (Insecure Direct Object Reference - IDOR zafiyetini önlemek) için mükemmeldir.
❌ Yanlış Kullanım Alanları
Büyük boyutlu (36 Bayt) oldukları için geleneksel B-Tree (Örn: MySQL InnoDB) indekslerinde parçalanmaya (Fragmentation) neden olurlar. Çok yüksek okuma/yazma (I/O) olan tablolarda "Primary Key" olarak kullanmak yerine UUID v7 veya "Snowflake ID" (Twitter algoritması) tercih edilebilir.
Geliştirici S.S.S.
UUID'ler "Case-Sensitive" (Büyük/Küçük harf duyarlı) midir?
Hayır. RFC 4122 standartlarına göre UUID'ler Hexadecimal (On altılık) karakterlerden oluşur ve A-F harflerinin büyük veya küçük yazılması hiçbir şeyi değiştirmez. Ancak, sistemler arası entegrasyonlarda uyumsuzluk olmaması adına tüm karakterlerin küçük harf (lowercase) kullanılması global bir best-practice'tir.
Veritabanında (SQL) UUID hangi veri tipinde saklanmalıdır?
Bunu standart VARCHAR(36) olarak saklamak korkunç bir performans israfıdır. Eğer PostgreSQL kullanıyorsanız native UUID veri tipini kullanın. MySQL/MariaDB kullanıyorsanız UUID'yi "Binary" (16 Byte) formatına çevirerek BINARY(16) sütunlarında indekslemeniz arama hızınızı %400 artırır.
Kriptografik Güvenlik ve Sıfır Saklama
Üretilen tüm UUID ve rastgele anahtarlar tarayıcınızın donanımsal entropi havuzuna bağlı crypto.getRandomValues() API'siyle üretilir. Üretilen ID'ler hiçbir sunucuya kaydedilmez ve geriye dönük tahmin edilemez.