Mengapa Tidak Menggunakan Auto-Increment ID?

Mengapa Tidak Menggunakan Auto-Increment ID Secara Default?

1. Masalah dengan Auto-Increment ID

• Orang dapat memperkirakan jumlah entitas:

  • Contoh: Jika ID pesanan terakhir adalah 1284, dapat diperkirakan ada sekitar 1284 pesanan sebelumnya.

  • Informasi ini seharusnya tidak bocor ke publik.

• Orang dapat menebak ID entitas lain:

  • Contoh: Jika URL video YouTube menggunakan auto-increment ID, pengguna bisa mencoba mengakses video lain dengan ID yang ditebak (misal: 51299 setelah melihat video 51298).

  • Ini berbahaya untuk konten yang seharusnya privat.

• ID tidak unik secara global:

  • Auto-increment ID bisa sama di tabel berbeda, berpotensi menyebabkan kesalahan saat operasi database (misal: salah update tabel karena ID sama).

  • Jika ID benar-benar unik global, operasi yang salah akan gagal, bukan berjalan dengan risiko data rusak.

• Sulit untuk migrasi database:

  • Saat migrasi (misal: dari SQL Server ke PostgreSQL), auto-increment ID harus disinkronkan.

  • Jika tidak, bisa terjadi tabrakan ID setelah migrasi selesai.

2. Solusi Sementara untuk Masalah Auto-Increment ID

• Enkripsi ID sebelum dikirim ke publik:

  • Mencegah orang melihat pola ID asli.

• Penggunaan transaksi saat operasi manual di database:

  • Meminimalkan risiko kesalahan update.

• Reset auto-increment key setelah migrasi:

  • Memastikan ID baru tidak bertabrakan dengan yang lama.

3. Masalah Utama Auto-Increment ID

• Ketergantungan kuat pada database:

  • ID hanya bisa diketahui setelah data dimasukkan ke database.

  • Aplikasi tidak bisa menghasilkan ID sendiri sebelum operasi penyimpanan.

• Sulit untuk scaling:

  • Auto-increment ID biasanya dihasilkan oleh satu server database, menjadi bottleneck saat traffic tinggi.

  • Jika database dipartisi, sinkronisasi ID antar-instance jadi rumit karena harus mempertahankan sifat incremental dan unik.

4. Masalah dalam Arsitektur Modern (Eventual Consistency)

• Tidak cocok untuk sistem terdistribusi:

  • Contoh: Jika data perlu dimasukkan ke MySQL, Memcached, dan Elasticsearch secara konsisten, aplikasi harus menunggu ID dari MySQL terlebih dahulu.

  • Solusi alternatif (seperti menggunakan Kafka untuk eventual consistency) jadi lebih rumit karena ketergantungan pada ID yang dihasilkan database.

5. Solusi yang Lebih Baik: UUID atau Random ID

• UUID (Universally Unique Identifier):

  • Menghasilkan ID acak yang hampir pasti unik.

  • Tidak memerlukan koordinasi dengan database.

• Timestamp + Angka Acak:

  • Juga bisa digunakan untuk memastikan keunikan dengan risiko tabrakan sangat rendah.

6. Kesimpulan & Rekomendasi

• Auto-increment ID sebaiknya tidak digunakan secara default.

• UUID lebih direkomendasikan karena:

  • Tidak bergantung pada database.

  • Aman dari tebakan ID.

  • Cocok untuk sistem terdistribusi.

• Gunakan auto-increment ID hanya jika benar-benar diperlukan (misal: untuk kebutuhan sequential yang spesifik).

• Relational database (seperti MySQL/PostgreSQL) seharusnya tidak selalu menggunakan auto-increment ID secara default, berbeda dengan MongoDB yang sudah menggunakan UUID.

Dengan menghindari auto-increment ID secara default, sistem menjadi lebih fleksibel, aman, dan mudah dikembangkan.