Yang Nggak Diajarkan Tutorial: Pelajaran dari Proyek dengan Puluhan Ribu User

Kalau kamu belajar Laravel dari YouTube atau Udemy, biasanya skenarionya selalu sama: bikin CRUD, tambah auth, deploy, selesai. Semua mulus, semua terkontrol.

Realitanya? Berbeda jauh.

Saya pernah mengerjakan sistem yang dipakai oleh hampir 90 ribu siswa di seluruh kota — dan bukan sistem yang diakses bergantian, tapi hampir bersamaan di jam masuk sekolah. Dari situ saya belajar beberapa hal yang tidak akan pernah ada di tutorial manapun, karena masalahnya baru muncul ketika sistem itu benar-benar hidup dan dipakai orang beneran.

1. "Works on My Machine" Adalah Awal dari Semua Masalah

Di local environment, semua terasa cepat. Database punya 10 record, tidak ada concurrent user, server tidak dibebani apa-apa. Wajar kalau semuanya mulus.

Masalah mulai ketika sistem naik ke production dan penggunanya bukan kamu sendiri. Yang biasanya terjadi: query yang "biasa aja" di local tiba-tiba butuh 3–5 detik di production karena datanya sudah ratusan ribu row. Dan kalau ada 500 user yang hit endpoint yang sama di waktu yang berdekatan? Selamat datang di timeout error.

Pelajaran yang saya ambil: biasakan testing dengan dataset yang mendekati kondisi nyata, bukan dummy data 10 baris. Sebelum deploy, saya sekarang selalu seed database dengan volume data yang realistis dan lihat bagaimana query plan-nya.

2. Index Database Bukan Fitur Opsional

Ini yang paling sering dilewatkan. Kita sibuk mikirin logic aplikasi, tapi lupa bahwa database juga butuh "petunjuk jalan" supaya tidak kebingungan waktu mencari data.

Saya pernah punya tabel dengan 80 ribu+ row, dan ada satu halaman yang loading-nya lama banget. Setelah dicek pakai EXPLAIN di MySQL, ternyata query-nya melakukan full table scan — artinya database membaca satu per satu dari awal sampai akhir setiap kali ada request.

Solusinya? Tambah index di kolom yang sering jadi filter (WHERE) atau sorting (ORDER BY). Waktu loading turun drastis. Tidak perlu upgrade server, tidak perlu refactor besar-besaran. Cukup satu baris di migration:

$table->index(['kolom_yang_sering_difilter']);

Sederhana, tapi efeknya nyata.

3. Jangan Percaya User Akan Pakai Sistem Sesuai Ekspektasi Kamu

Ini lebih ke sisi human behavior, tapi tetap berpengaruh ke teknis.

Waktu saya bangun sistem absensi, asumsinya guru akan scan QR Code satu per satu secara tertib. Kenyataannya? Ada yang scan berkali-kali karena tidak yakin berhasil, ada yang sistemnya dipakai oleh beberapa orang di waktu yang sama dari device berbeda, ada yang koneksi internetnya buruk jadi retry-nya double bahkan triple.

Akibatnya: data duplikat, race condition di database, dan laporan absensi yang kacau.

Dari sini saya mulai serius soal idempotency — memastikan satu aksi yang dilakukan berkali-kali tidak menghasilkan data ganda. Di Laravel, ini bisa diatasi dengan kombinasi firstOrCreate, unique constraint di level database, dan validasi yang lebih ketat di backend. Jangan hanya andalkan validasi di frontend.

4. Log Itu Investasi, Bukan Beban

Waktu masih junior, saya sering skip implementasi logging karena terasa tidak perlu. "Toh bisa dilihat dari database langsung."

Begitu sistem punya ribuan transaksi per hari dan ada bug yang laporan masuknya H+3 setelah kejadian — barulah sadar betapa pentingnya log yang proper. Tanpa log, debugging jadi seperti investigasi tanpa barang bukti.

Sekarang saya selalu implementasi logging untuk aksi-aksi kritis: siapa yang melakukan apa, kapan, dari IP mana, dan hasilnya sukses atau gagal. Di Laravel sudah tersedia:

Log::info('User berhasil absen', ['user_id' => $user->id]);
Log::warning('Duplikat scan terdeteksi', ['qr_token' => $token]);
Log::error('Gagal simpan ke database', ['error' => $e->getMessage()]);

Untuk level lebih serius, bisa pertimbangkan integrasi ke Sentry atau Papertrail.

5. Komunikasi dengan Stakeholder Sama Pentingnya dengan Koding

Ini yang paling tidak saya sangka bakal sepenting ini.

Di proyek skala besar, terutama yang melibatkan instansi atau klien non-teknis, kemampuan menjelaskan masalah teknis dalam bahasa yang mudah dipahami itu krusial. Bukan karena mereka perlu tahu cara kerjanya — tapi karena kalau ada kendala atau delay, mereka butuh penjelasan yang masuk akal, bukan jargon.

Saya belajar untuk selalu siapkan "terjemahan" dari setiap masalah teknis: bukan "ada bottleneck di query N+1", tapi "sistem sedang memproses terlalu banyak data sekaligus dan butuh optimasi dulu sebelum bisa stabil."

Proyek besar itu bukan cuma soal nulis kode yang bagus. Banyak hal yang baru kelihatan ketika sistemnya sudah beneran dipakai — dan itulah yang bikin proses belajarnya tidak pernah berhenti.

Kalau kamu pernah punya pengalaman serupa atau ada hal lain yang kamu pelajari dari proyek dengan skala besar, feel free share di komentar.