Ask HN: Saya mengalami tabrakan UUID v4 yang nyata...

 (news.ycombinator.com)
1 poin oleh GN⁺ 2 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • Basis data hari ini mendeteksi UUID v4 duplikat, dan nilainya ternyata persis sama dengan b6133fd6-70fe-4fe3-bed6-8ca8fc9386cd pada record yang ditambahkan pada 2025
  • Paket yang digunakan adalah uuid dari npm, dan katanya UUID dibuat dengan cara import { v4 as uuidv4 } from "uuid"; lalu const document_id = uuidv4();, kemudian dimasukkan ke basis data
  • Basis data itu hanya memiliki sekitar 15.000 record, jadi secara statistik tampak mustahil, dan ia bertanya apakah ada orang lain yang pernah mengalami hal yang sama

Bacaan terkait

1 komentar

 
GN⁺ 2 jam lalu
Komentar Hacker News

  • jandrewrogers: Ini ternyata cukup umum. Keamanan UUIDv4 bergantung pada asumsi bahwa ada sumber entropi berkualitas tinggi, tetapi asumsi ini mudah rusak karena cacat perangkat keras, bug perangkat lunak biasa, atau kurangnya pemahaman pengembang tentang entropi
    Mendeteksi apakah sumber entropi rusak itu cukup mahal, jadi hampir tak ada yang melakukannya, dan akhirnya baru ketahuan setelah tabrakan terjadi. Karena itu, di banyak sistem dengan keandalan dan jaminan tinggi, UUIDv4 secara eksplisit dilarang

    • LocalH: Itulah mengapa CloudFlare membuat sesuatu seperti dinding lava lamp. Bukan karena itu sendiri sumber entropi yang luar biasa besar, melainkan karena efeknya membuat konsep entropi dan pembangkitan angka acak menjadi terlihat bahkan bagi orang yang tidak terlalu memahaminya
      Semakin banyak sumber entropi, semakin baik, dan cukup banyak di antaranya harus non-deterministik. Bahkan dalam game skala kecil, jika nilai seperti koordinat mouse, jeda antar input tombol, atau jumlah frame sebelum tombol start ditekan dicampurkan ke seed awal, maka meskipun secara internal tetap memakai pseudorandom generator, hasilnya jauh lebih sulit diprediksi. Saya akan kecewa jika CloudFlare memakai kurang dari 100 sumber entropi
    • Groxx: Saya pernah melihat duplikasi yang tampak masuk akal pada perangkat keras yang rusak. Di beberapa pustaka UUID juga sangat umum ada pola duplikasi dengan bagian belakang dipenuhi angka 0
      Ini terjadi bila nilai balik seperti “meminta N byte tetapi hanya 3 byte yang dikembalikan, jadi harus meminta lagi N-3 byte” tidak divalidasi, seperti yang dulu pernah terjadi di Go. Pada kebanyakan perangkat keras atau sistem operasi ini jarang meledak, jadi orang tidak mengeceknya, lalu suatu hari di lingkungan produksi baru terlihat ada puluhan ribu tabrakan
    • thecloud: Saya penasaran, di sistem berkeandalan tinggi orang memakai alternatif apa sebagai pengganti UUIDv4

  • throwaway_19sz: Sulit dipercaya dan lucu, tapi ini nyata. Sepuluh tahun lalu seorang teman bergabung sebagai CTO di startup yang tumbuh sangat cepat, perusahaan dengan sekitar 200 developer, dan pada minggu pertamanya dia menemukan ada microservice khusus pembuat UUID
    Untuk satu endpoint saja ada 3 engineer khusus, bahkan ada juga orang database. Setiap tim harus memanggil layanan ini bila butuh UUID baru yang “aman”, dan layanan itu akan membuat UUID, mengecek di DB internalnya apakah UUID itu sudah pernah diterbitkan, lalu jika belum akan disisipkan dan dikembalikan. Entah demi ketenangan batin atau apa, tim itu bahkan punya papan kanban dan sprint sendiri

    • Aurornis: Di awal karier saya bekerja di startup dengan sumber daya terbatas, jadi setiap kali membuat sesuatu atau merekrut orang, semua diputuskan dengan hati-hati. Pada masa itu, cerita ini akan terdengar seperti fiksi
      Startup yang saya masuki kemudian malah selalu membuat microservice baru dan tim baru setiap kali seseorang menemukan kekhawatiran baru. Target kuartalan secara eksplisit adalah memperbesar ukuran tim engineering, dan tim-tim beranggotakan 3~4 orang menciptakan pekerjaan mereka sendiri lewat sprint dan rapat perencanaan mereka. Saya pernah mengusulkan agar personel dari proyek yang stabil dipindahkan ke pekerjaan mendesak, tetapi ditolak karena bertentangan dengan KPI yang mewajibkan jumlah engineer mencapai angka tertentu
    • wongarsu: Suatu saat pasti ada yang mengoptimalkan semuanya dengan counter 128-bit bertambah global tingkat perusahaan. Ambil saja counter saat ini, tambah 1, lalu bagikan tanpa perlu query ke DB yang terus membesar, maka jadinya O(1) dan cepat
      Untuk ketersediaan tinggi dan deployment global, ini juga bisa di-shard dengan memberi tiap instance rentang ID khusus. Sisihkan sebagian bit atas untuk ID data center dan beberapa bit lagi untuk instance pembuat ID di dalamnya. Tunggu, rasanya saya pernah melihat ini di suatu tempat… Saya penasaran apakah Twitter masih memakai cara ini, atau akhirnya menggantinya
    • roryirvine: Saya pernah melihat sesuatu yang mirip jauh di dalam perusahaan teknologi besar Silicon Valley. Hanya saja daftar utama UUID yang dipakai ada di layanan CMDB eksternal yang dikelola departemen lain, jadi prosedurnya lebih rumit
      Setiap hari mereka mengambil dump DB untuk pengecekan saat membuat ID “sementara”, dan baru menjadi “final” setelah benar-benar diserahkan ke CMDB. Ada guardrail agar ID sementara tidak dipakai di produksi, dan ada juga prosedur untuk mendaur ulang ID final yang tidak terpakai. Terakhir saya dengar, mereka sudah 18 bulan menjalankan proyek 6 bulan untuk memindahkan cache DB lokal ke Zookeeper

  • CodesInChaos: Biasanya ini terjadi karena pseudorandom generator dengan seed yang buruk. Penting apakah UUID dibuat di backend atau frontend
    Frontend pada dasarnya sulit dipercaya karena berbagai alasan, termasuk tabrakan yang disengaja, jadi penanganan tabrakan tetap diperlukan. Backend bisa dibuat andal. Dulu VM memang pernah punya masalah seperti ini, tetapi seharusnya sekarang sudah teratasi, meski proses yang sangat tersandbox dan memakai jalur fallback angka acak yang tidak aman masih bisa kena. Fork proses atau VM juga bisa membuat tabrakan karena menyalin state

    • danpalmer: Saya pernah dengar bahwa perusahaan analitik bernama Segment menggantungkan seluruh produknya pada UUID yang dibuat di web browser. Ada tabrakan UUID browser di sana-sini, sehingga produknya sepertinya secara mendasar tidak bisa menghasilkan data yang berguna. Semoga sekarang sudah diperbaiki

  • kst: Ini mengingatkan saya pada satu bagian di “Pro Git”. <https://git-scm.com/book/en/v2>
    Contohnya, kalau 6,5 miliar orang di bumi semuanya setiap detik membuat kode sebesar seluruh riwayat Linux kernel dan mendorongnya ke satu repositori Git raksasa, tetap butuh kira-kira 2 tahun agar peluang tabrakan objek SHA-1 mencapai 50%. Jadi saya suka ungkapan bahwa peluang tabrakan SHA-1 alami lebih kecil daripada peluang semua anggota tim Anda mati pada malam yang sama karena serangan serigala yang tak saling berkaitan. SHA-1 hash bukan angka acak dan 160-bit, jadi berbeda dari UUIDv4, tetapi saya suka analogi serangan serigala yang tak saling berkaitan itu

    • mega_dean: Ini mengingatkan saya pada halaman yang menjelaskan betapa besarnya jumlah permutasi satu set kartu: https://czep.net/weblog/52cards.html
      Analogi semacam: berjalan mengelilingi bumi dari khatulistiwa satu langkah tiap 1 miliar tahun, tiap satu putaran mengambil setetes air dari Samudra Pasifik, dan setelah samudra habis menumpuk selembar kertas, lalu mengulanginya sampai tumpukan itu mencapai matahari, namun tiga digit pertama pada timer 52! detik tetap tidak berubah
    • swiftcoder: Sebaliknya, serangan kamus cukup realistis, dan seperti bisa dibuktikan oleh orang-orang yang tanpa pikir panjang pernah meng-commit file test case itu ke Git, hal ini cukup merepotkan
    • TacticalCoder: Bukankah tim Git sedang bekerja keras agar selain SHA-1 juga ada opsi hash lain seperti SHA256?

  • e12e: Ada pembahasan terkait di sini: https://github.com/uuidjs/uuid/issues/546
    Misalnya disebutkan bahwa saat crypto.getRandomValues() diuji di googlebot, hasilnya deterministik

    • D2OQZG8l5BI1S06: Masuk akal. Tapi saya tidak paham kenapa orang membuat UUID di browser. Rasanya itu justru merusak tujuannya

  • adyavanapalli: Kejadian yang dibicarakan ini sangat langka, sampai-sampai kemungkinan bumi dihancurkan asteroid tepat saat ini lebih besar

    • thomasmg: Tidak selangka itu. Saya pernah menghitungnya, dan memang lebih jarang daripada tertimpa meteorit, lalu saya pernah menambahkan hal itu bersama masalah ulang tahun ke artikel UUID di Wikipedia. Beberapa tahun lalu dihapus dan diganti, sih
      Saya pernah dengar ada perempuan yang benar-benar tertimpa meteorit tetapi selamat dengan cedera kaki. Jika terjadi tabrakan UUID, kemungkinan yang sangat dominan adalah bug perangkat lunak atau anomali komputer, meski bisa juga sinar kosmik. Sinar kosmik yang mengganggu memori atau CPU lebih umum daripada dugaan orang
    • delichon: Kira-kira sebesar peluang asteroid mengetik elipsis lalu menekan tombol tambah komentar
    • spindump8930: Seperti yang orang lain bilang, kalau seed-nya salah, ini justru sangat umum. Kalau mau pakai analogi, seperti peluang bumi tertabrak saat dikelilingi sabuk asteroid fiksi ilmiah yang sangat padat

  • juancn: Apakah inisialisasi generator angka acaknya aneh atau entropinya kurang? Jika tidak dikustomisasi, biasanya yang dipakai adalah crypto.getRandomValues(rnds8), dan getRandomValues tidak menyatakan jumlah minimum entropi

    • Hizonner: Hampir pasti generator angka acaknya rusak parah, kemungkinan besar masalah penanganan seed. Sangat mungkin ini juga merusak kriptografi mereka

  • Geee: Menurut interpretasi banyak dunia dalam mekanika kuantum, pasti ada satu cabang alam semesta tempat semua UUID sama. Saya membayangkan seperti apa pikiran orang-orang di sana

    • suprjami: Mungkin setelah membuat “UUID itu”, mereka cukup menambahkan angka bertambah di belakangnya agar tetap unik. Masalah selesai
    • BobaFloutist: Bukan cuma itu, pasti ada jauh lebih banyak alam semesta yang semuanya sama kecuali satu UUID. Hanya saja UUID yang satu itu belum sempat mereka pakai. Atau alam semesta tempat hanya dua UUID pertama yang unik, dan setelah itu semua UUID selalu salah satu dari dua itu
    • nyantaro1: Itulah mengapa saya kurang suka pendekatan Everett

  • mittermayr: Saya sangat setuju bahwa ini terdengar tidak masuk akal. Tapi kalau menebak, dulu mereka membuat UUIDv4 di ponsel pengguna lalu mengirimkannya ke DB, sedangkan UUID yang bentrok pagi ini dibuat di server Ubuntu, dan itulah bedanya
    Saya tidak tahu bagaimana tepatnya UUIDv4 dibuat atau apakah karakteristik mesin pembuat ikut masuk ke algoritmenya, tetapi satu-satunya perubahan yang terpikir adalah bahwa dulu dibuat di perangkat, lalu beberapa bulan lalu mulai dibuat di server

    • AntiUSAbah: Maksudnya Anda membiarkan pengguna membuat UUID? Jujur saya merasa kemungkinan ada implementasi aneh lebih besar daripada tabrakan UUID sungguhan. Saya penasaran bagaimana DB menandai tabrakan itu
    • wongarsu: Jika keduanya adalah UUID yang dibuat di perangkat, saya bisa mengerti peluang tabrakannya. Ada kasus terminal murah yang seed generator angka acaknya tidak terinisialisasi dengan benar sehingga nilai “acak” bertabrakan, dan akan lebih parah jika pustakanya memakai generator murahan alih-alih CSPRNG yang benar
      Tapi di server, apalagi pada 2026, itu seharusnya tidak boleh terjadi. Dulu seed angka acak pada VM memang bermasalah, tetapi sekarang seharusnya lebih baik. Bahkan jika satu UUID dibuat dengan buruk, peluang UUID yang benar-benar acak menabraknya tetap sangat kecil, jadi kedua generatornya kemungkinan sama-sama bermasalah
    • stubish: Tabrakan UUIDv4 secara statistik sangat, sangat kecil. Penjelasan yang lebih masuk akal adalah kedua sistem memakai seed yang sama. Jika seed-nya hanya beberapa byte, kemungkinan tabrakannya bisa naik dari sepermiliar menjadi sepersejuta atau semacam itu

  • dweez: Sudah waktunya membaca ulang tulisan menarik ini: https://jasonfantl.com/posts/Universal-Unique-IDs/
    Jika seluruh alam semesta diubah menjadi komputer raksasa yang hanya membuat UUID sampai heat death, berapa bit yang dibutuhkan ruang ID itu?

    • CodeWriter23: Kalau sudah sejauh itu, yang ini wajib: https://www.decisionproblem.com/paperclips/
    • ipaddr: Contoh “apakah sekarang Anda khawatir semua manusia di bumi tertimpa meteorit” mungkin kurang bagus. Satu meteorit bisa mengakhiri dunia, dan jika diberi cukup waktu, kemungkinannya jadi tinggi

  • beejiu: Saya penasaran apakah UUID dibuat di sisi klien atau sisi server. Kalau di sisi klien, bisa jadi karena bot crawler. Misalnya, Googlebot menjalankan JavaScript dengan “keacakan” yang deterministik

    • adzm: Pada insiden sebelumnya di paket itu, kesimpulannya juga memang karena kurangnya keacakan Googlebot: https://github.com/uuidjs/uuid/issues/546
    • AgentME: Hampir pasti ini salah satunya, atau mereka memakai versi lama dari paket yang gagal memakai generator angka acak sistem dengan benar, atau memuat polyfill tua dan rusak yang mengimplementasikan ulang JS crypto API, atau konfigurasi hosting aneh yang melanjutkan snapshot VM yang sama di beberapa server sehingga state angka acaknya tersalin
      Penjelasan seperti ini jauh beberapa orde magnitudo lebih masuk akal daripada tabrakan acak sungguhan

  • merlindru: Besar kemungkinan masalah seed. Jika Anda bisa membuktikan bukan itu, Anda mungkin akan sedikit terkenal

  • erlkonig: Saya selalu bilang ke tim bahwa jika datanya cukup banyak, nilai acak pada akhirnya bisa bertabrakan, dan saat itu kita akan melihat seberapa tangguh perangkat lunak kita
    Meski begitu, masih banyak developer senior, lead tim, dan CIO yang percaya itu mustahil dan sama sekali tidak menulis kode untuk menangani situasi tersebut. Akibatnya generator angka acak yang buruk bisa merusak sistem jauh lebih cepat dari dugaan, dan kerusakan simultan pun mungkin terjadi tanpa deteksi atau regenerasi. Rasanya sama seperti golongan orang yang tidak memeriksa apakah malloc() berhasil. Saya kadang bertanya, “Kalau memang mustahil, bukankah berarti kita memakai terlalu banyak bit?”

  • leni536: Ini bukan terjadi secara kebetulan, ada bug di suatu tempat. Sepintas kelihatannya paket itu memanggil crypto.randomUUID() dari runtime JS, dan ini seharusnya selalu di-seed dengan benar
    Kemungkinan bug pada runtime tampak sangat kecil, tapi siapa tahu. Saya penasaran runtime JS apa yang dipakai

  • jbverschoor: Penyebab yang paling masuk akal adalah paket angka acak yang menjadi dependensi uuid baru-baru ini dikompromikan sehingga angka “acak” bisa diprediksi. Akibatnya, banyak proyek terkait kriptografi, SSL, dan mata uang bisa ikut berisiko karena serangan rantai pasok

    • jbverschoor: Tiga minggu lalu, di uuid/src/rng.ts, array acak diubah menjadi const. Semua pemanggilan jadi berbagi array acak yang sama
      Pemanggilan berikutnya akan memperbarui kode acak sebelumnya, jadi kalau Anda membuat sesuatu yang penting, semoga beruntung. Kode lama membuat salinan baru dengan slice(). Mungkin ini perubahan yang tidak disengaja, tetapi saya tidak mengerti bagaimana bisa lolos, karena rasanya tes yang membuat dua angka acak lalu mengecek apakah keduanya berbeda pun tidak akan lolos

  • pif: Bahkan dengan sumber entropi berkualitas tinggi, Anda tidak bisa mengubah “kemungkinan besar begitu” menjadi “pasti begitu”. Jika Anda butuh nilai yang sulit ditebak, cari solusi kriptografi, tetapi jika Anda butuh keunikan yang terjamin, Anda harus membuatnya sendiri

  • athrowaway3z: Aturan praktis yang sederhana adalah memikirkan apakah ID bisa memasukkan timestamp selain nilai acak. Biasanya jawabannya ya, dan UUIDv7 sudah cukup
    Jika Anda sudah menelaah masalah ini sedalam sampai bisa menulis pembuktian bahwa kebocoran informasi tidak dapat diterima, selamat. Sistem itu mungkin cukup kompleks dan lambat sehingga lebih cocok memakai hash kriptografis yang kuat, atau kalau malas cukup UUIDv5

  • darqis: PostgreSQL 18 mendukung uuidv7 secara native, dan default-nya bisa cukup unique dan uuid7()

  • tumdum_: Itu pseudorandom generator dengan seed buruk

  • serf: Peluangnya sekitar 1 banding 4,72 × 10²⁸, atau sekitar 1 banding 47,3 oktiliun. Kalau ini benar, sebelum beli lotre saya justru akan curiga pada race condition atau kesalahan sederhana lain

    • petee: Saya malah selalu melihatnya sebaliknya. Kalau Anda sudah seberuntung itu, kemungkinan keberuntungan lain datang lagi justru lebih kecil, jadi saatnya hemat uang
    • k4rli: Bicara lotre tidak masuk akal. Secara statistik, kalau sesuatu yang sangat langka itu sudah terjadi, maka peluang terulang lagi mestinya lebih langka lagi

  • evnix: Bahkan tanpa membahas matematika probabilitas, realitas tempat kita hidup ini membuat bahkan generator angka acak perangkat keras terbaik pun bisa kurang acak dari yang kita kira
    Jika keamanan bukan hal penting, saya akan pindah ke sesuatu seperti TSID, atau ke uuidv7, agar dalam praktik kejadian seperti ini nyaris tidak terjadi. Menurut saya itu lebih baik daripada overengineering kode dengan retry

  • jordiburgos: Tolong jangan pakai b6133fd6-70fe-4fe3-bed6-8ca8fc9386cd. Saya cek DB saya, ternyata sudah dipakai

    • rich_sasha: Saya selalu merasa membuat UUID secara acak itu gila. Sekarang saya cuma pakai LLM. Prompt-nya adalah “Buat UUID. Pastikan tidak pernah dipakai siapa pun di kode atau database mana pun. Tinjau pekerjaanmu dan pikirkan mendalam di setiap langkah. Jangan keluarkan penalaran atau bahasa Inggris biasa, keluarkan hanya UUID-nya.” Sama-sama
    • mittermayr: Sudah kuduga. Kita semua cuma dapat UUID murahan yang sama, sementara UUID bagus dicadangkan untuk para pemain besar
    • robshep: Saya memakai 16b55183-1697-496e-bc8a-854eb9aae0f3, dan mungkin ada lagi. Kalau semua orang memposting daftar mereka di sini, mungkin kita bisa mengecek duplikat?

  • pyuser583: Saya penasaran, UUID apa yang sekarang paling disukai orang

  • smokel: Sudah berkali-kali saya menyalahkan compiler, sinar kosmik, efek kuantum, atau minimal bug kernel yang aneh, lalu akhirnya sadar bahwa sumber bug-nya adalah saya sendiri
    Tabrakan pada 15.000 record terlalu kecil kemungkinannya, jadi saya akan lebih dulu mencurigai penyebab lain: penanganan duplikasi, request yang terkirim ulang, objek yang dipakai ulang, log yang menyesatkan, atau penggunaan ulang identifier dari jalur kode lain. Kalau Anda membagikan sedikit lebih banyak kode di sekitarnya, mungkin kita bisa ikut memeriksa

  • wazoox: Belum pernah terjadi pada saya, tapi dua hari lalu saya menemukan ini jauh di dalam codebase PHP produksi: fungsi createUUID() yang memotong nilai dari md5(uniqid('', true)) lalu menempelkannya agar berbentuk seperti UUID
    Saya tidak tahu bagaimana kengerian seperti ini sampai sekarang belum menggigit titik lemah kami

  • sedatk: Di uuidjs/uuid ada peringatan bahwa klien dengan generator angka acak deterministik seperti Googlebot dapat menghasilkan UUID duplikat
    Disebutkan bahwa ini bisa jadi masalah untuk aplikasi yang mengharapkan UUID buatan klien selalu unik, sehingga perlu strategi untuk memeriksa duplikasi dan gagal dengan elegan, atau menonaktifkan operasi tulis dari klien Googlebot: https://github.com/uuidjs/uuid/commit/91805f665c38b691ac2cbd...

  • xyzzy123: Saya pernah mengalami load test jangka panjang pada sistem terdistribusi berbasis Linux gagal karena UUID duplikat
    Setelah penyelidikan panjang, ternyata itu bug kernel, tepatnya race condition. Pada sistem multiprosesor, jika dua proses membaca /dev/random secara bersamaan, dalam kasus yang sangat langka, kira-kira 1 banding sejuta, mereka bisa menerima byte yang sama. Saya mungkin akan lebih dulu memeriksa inisialisasi generator angka acak

  • baq: Sepertinya VM yang berjalan telah membuang semua entropi lewat virtualisasi

  • glaslong: Sepertinya saya perlu beli beberapa lava lamp

  • 0xfffafaCrash: Saya penasaran apakah UUID dibuat di frontend atau backend. Jika di frontend, daripada masalah entropi saya akan lebih bertaruh bahwa kode klien atau request dimanipulasi untuk menyuntikkan UUID yang sudah diketahui

  • latentframe: Salah satu kalimat paling berbahaya dalam engineering adalah secara statistik mustahil. Pada skala yang cukup besar, kasus ekstrem berhenti jadi teori dan berubah menjadi kejadian operasional

  • 8organicbits: Tahun lalu saya pernah menulis soal tabrakan nyata, termasuk pustaka yang terlibat: https://alexsci.com/blog/uuid-oops/
    Agar UUID tahan terhadap tabrakan, ada banyak batasan yang harus dipatuhi dengan ketat, dan dalam kasus ini tampaknya besar kemungkinan ada masalah pada generator angka acaknya

  • nu11ptr: Pada akhirnya ini masalah sumber entropi. Karena itu saya selalu membuat dan menyisipkannya di dalam loop. Kalau terjadi tabrakan, saya bisa menanganinya dengan elegan

  • sbuttgereit: Ini bukan “secara teknis mustahil”. Ini sangat mungkin secara teknis. Jika keacakannya bagus, peluangnya hanya sangat, sangat kecil, dan tidak ada apa pun pada UUIDv4 yang secara teknis mencegahnya menghasilkan nilai duplikat

  • beardyw: Mungkin ini pertanyaan bodoh, tapi kenapa tidak menambahkan tanggal, setidaknya dalam bentuk detik heksadesimal? Rasanya dengan menambah beberapa byte saja, sesuatu yang aman sekarang bisa tetap dijamin aman di masa depan

    • flohofwoe: Anda bisa memakai varian UUID lain yang menyertakan data timestamp. Misalnya v1 atau v7, dan ada juga varian yang menyertakan alamat MAC
    • itsyonas: Tinggal pakai uuidv7
    • mittermayr: Ya, bentuk data semi-acak tambahan apa pun mungkin akan membantu mencegah hal seperti ini. Tapi bukankah itu juga ide dasar UUIDv4? Saya tadinya mengira sudah ada banyak keacakan dan waktu di dalamnya

  • mdavid626: Ada penjelasan lain juga. Misalnya seseorang memodifikasi request secara manual, atau mengutak-atik DB

  • radial_symmetry: Saya juga pernah mengalami hal seperti ini sekali dan sempat merasa saya mulai gila, jadi membaca komentar-komentar di sini membuat saya lega

  • NKosmatos: Ini bukan “secara teknis mustahil”. Bukan mustahil, hanya sangat, sangat kecil kemungkinannya. Mungkin Anda harus beli tiket lotre
    Setiap kali saya memakai kata “improbable”, saya teringat https://hitchhikers.fandom.com/wiki/Infinite_Improbability_D...

    • sebazzz: Justru jangan beli lotre. Tabrakan itu dan menang lotre sekaligus akan lebih jarang lagi
    • rithdmc: Benar-benar tak terpikirkan

  • sudb: Untuk pertama kalinya saya merasa keputusan memilih CUID2 di salah satu proyek saya ternyata memang ide yang bagus: https://github.com/paralleldrive/cuid2