Bagaimana Saya Mengeliminasi Race Condition di API Tiket High-Concurrency.

Ringkasan Eksekutif: Untuk mengeliminasi race condition pada sistem tiket konkurensi tinggi, saya mengimplementasikan klausa FOR UPDATE dari PostgreSQL untuk row-level locking dan channel worker Go untuk serialisasi antrean di memori. Pendekatan ini mencegah over-selling inventaris dengan menjamin eksekusi mutasi data tunggal bahkan di bawah beban flash-sale.

Jika Anda pernah membangun aplikasi yang menangani tiket acara langsung, flash sale, atau perilisan inventaris terbatas, Anda pasti tahu ketakutan akan lalu lintas yang meledak (burst traffic). Tantangan teknis utamanya bukan hanya meningkatkan skala server—tetapi mempertahankan integritas data yang absolut ketika seribu pengguna mencoba mengubah baris database yang sama persis pada milidetik yang sama.

Tanpa kontrol konkurensi yang ketat, Anda akan mendapatkan race condition. Dua pengguna membeli tiket terakhir, database memproses kedua pembacaan (read) sebelum penulisan (write) di-commit, dan tiba-tiba, Anda memiliki acara yang kelebihan penjualan dan klien yang marah. Berikut adalah cara saya menyelesaikan masalah ini menggunakan Go (Golang) dan PostgreSQL.

Mengapa Go?

Saya memilih Go karena model konkurensinya. Goroutine sangat ringan dibandingkan dengan thread OS tradisional, yang memungkinkan API to menggandakan (multiplex) ribuan permintaan HTTP yang masuk melintasi sejumlah kecil thread. Ditambah dengan framework Gin, lapisan routing dengan mudah mempertahankan RPS (Requests Per Second) yang masif tanpa menghabiskan RAM.

Leher Botol Database

Membangun sistem dengan konkurensi tinggi membutuhkan lebih dari sekadar memilih bahasa yang cepat; ini membutuhkan desain hati-hati di seluruh lapisan stack (database, aplikasi, dan cache). Saat berhadapan dengan data inventaris berharga, optimisme naif mengarah pada kerusakan data. Kunci untuk menghilangkan kondisi balapan bukanlah mencegah permintaan bersamaan, melainkan menserikannya di bottleneck yang tepat menggunakan jaminan basis data yang kuat.

Pelajaran paling berharga di sini adalah mendelegasikan integritas transaksional kepada alat yang dibangun untuk itu: PostgreSQL. Aplikasi Go tetap menjadi fasilitator tanpa kewarganegaraan (stateless) yang cepat, sementara basis data menangani perlindungan mutasi akhir. Pemisahan tanggung jawab ini pada akhirnya yang memungkinkan API tersebut untuk bertahan hidup di bawah tekanan produksi.

Pendekatan naif yang khas adalah pemeriksaan di tingkat aplikasi:

// ❌ BAD PATTERN (Race Condition prone)
ticket := db.FindTicket(id)
if ticket.Status == "AVAILABLE" {
    db.UpdateTicket(id, "SOLD", userID)
}

Pada saat UpdateTicket dieksekusi, goroutine lain kemungkinan besar telah membaca statusnya sebagai "AVAILABLE".

Solusi: Row-Level Locking

Untuk memperbaikinya, kita harus mendorong kontrol konkurensi ke dalam transaksi PostgreSQL dengan memanfaatkan klausa FOR UPDATE.

// ✅ SECURE PATTERN
tx := db.Begin()

// Lock the specific ticket row until this transaction completes
var ticket Ticket
tx.Raw("SELECT * FROM tickets WHERE id = ? FOR UPDATE", id).Scan(&ticket)

if ticket.Status != "AVAILABLE" {
    tx.Rollback()
    return ErrTicketAlreadySold
}

// Mark as sold and commit
tx.Exec("UPDATE tickets SET status = 'SOLD', user_id = ? WHERE id = ?", userID, id)
tx.Commit()

SELECT ... FOR UPDATE menginstruksikan PostgreSQL untuk menempatkan kunci eksklusif pada baris yang diambil. Jika 1.000 permintaan mencoba mengeksekusi ini secara bersamaan, PostgreSQL memaksa mereka masuk ke dalam antrean. Permintaan pertama mengunci baris, memperbaruinya, dan melakukan commit. Ketika permintaan kedua akhirnya diberikan kunci, ia membaca status yang telah diperbarui, melihat bahwa tiket tidak lagi tersedia, dan dengan aman dibatalkan (rollback).

Hasilnya

Arsitektur ini menjamin 100% integritas data tanpa adanya pemesanan ganda (zero double-bookings), bahkan di bawah beban yang ekstrem. Konsekuensinya adalah persaingan database (database contention), tetapi karena transaksinya sangat cepat (membaca dan memperbarui satu baris yang diindeks), durasi penguncian diukur dalam mikrodetik.