Rembayung: Bila Sistem Booking Berdepan Traffic Tinggi dan Isu Scalping
Published:
Updated:
Baru-baru ni aku tertarik dengan satu masalah yang berlaku dengan Rembayung.
Bukan sebab nak cari salah siapa.
Actually, aku rasa masalah macam ni menarik dari sudut software engineering.
Sebab bila sebuah restoran tiba-tiba jadi sangat popular, sistem booking yang selama ni "okay" boleh tiba-tiba jadi bottleneck.
Dan dalam kes Rembayung, aku nampak ada dua masalah yang berbeza:
- Website booking menerima terlalu banyak traffic pada masa yang sama.
- Seat booking boleh disalahgunakan oleh scalper.
Masalah pertama ialah masalah traffic dan capacity.
Masalah kedua pula ialah masalah business model dan ownership reservation.
Dua-dua tak patut diselesaikan dengan cara yang sama.
Dan bila aku fikir balik, sebenarnya aku pernah bina sebahagian daripada solution untuk masalah kedua ni sebelum ni untuk sebuah restoran, Efa Western.
Jadi aku cuba pecahkan case ni dari sudut aku.
Apa yang berlaku dengan Rembayung?
Semasa pembukaan tempahan Rembayung, website dilaporkan mengalami masalah selepas beberapa minit sahaja dibuka.
Sinar Harian melaporkan platform tempahan mengalami gangguan selepas lima minit dan 2,641 pelanggan berjaya mendapatkan slot. Beberapa laporan lain pula meletakkan jumlah booking pada sekitar 3,000 pelanggan.
Bagi aku, benda ni sebenarnya tak pelik.
Bayangkan sebuah restoran yang sangat popular.
Announcement dibuat.
Tarikh booking dibuka pada waktu tertentu.
Ribuan orang mungkin sudah tunggu dengan browser masing-masing.
Dan pada waktu yang sama:
10:00:00
Customer 1 → booking
Customer 2 → booking
Customer 3 → booking
Customer 4 → booking
...
Customer 3,000 → booking
Masalahnya bukan database semata-mata.
Bukan juga semata-mata server "tak cukup power".
Masalah sebenarnya ialah semua orang cuba masuk melalui pintu yang sama pada waktu yang sama.
Dan kemudian ada satu lagi masalah.
Scalper.
Ada laporan tentang individu yang mendakwa berjaya mendapatkan tujuh tempat dan kemudian menjualnya semula pada harga RM150 satu.
Jadi sekarang kita ada dua masalah:
Macam mana nak pastikan 3,000 orang tak menghentam booking server pada masa yang sama?
dan
Macam mana nak pastikan 200-ish seat yang terhad itu tidak menjadi komoditi untuk dijual semula?
Aku akan cuba solve dua benda ni secara berasingan.
Masalah pertama: Website kena hentam
Solution yang paling obvious ialah:
Waiting room.
Konsep ni bukan benda baru.
Ada platform seperti Queue-it yang memang dibina untuk situasi macam ni. User akan masuk waiting room dahulu, dan sistem akan control berapa ramai yang boleh masuk ke website sebenar pada satu-satu masa.
Konsepnya memang betul.
Cuma kalau aku bina untuk satu restoran atau untuk produk yang aku sendiri control, aku tak semestinya terus menggunakan Queue-it.
Bukan sebab Queue-it tak bagus.
Actually, konsep dia memang tepat untuk masalah ni.
Tapi bila tengok pricing, feature set dan positioning dia, aku rasa ia lebih sesuai untuk organisasi yang memang perlukan platform managed queue yang matang dan berskala besar.
Untuk use case yang lebih specific, aku mungkin akan buat sendiri.
Aku akan letak Cloudflare di depan
Architecture pertama yang aku akan fikir:
Customer
↓
Cloudflare
↓
WAF / Bot Protection / Rate Limit
↓
Waiting Room
↓
Booking Application
↓
Database
Cloudflare sendiri ada Waiting Room.
Idea asasnya mudah:
Kalau origin server hanya mampu handle 100 concurrent users dengan selesa, jangan bagi 5,000 orang masuk terus.
Biarkan Cloudflare tahan mereka di depan.
Kemudian lepaskan user sedikit demi sedikit.
Jadi bukannya:
5,000 users
↓
Laravel
↓
MySQL
💥 (BOOOM)
Tetapi:
5,000 users
↓
Cloudflare
↓
Waiting Room
↓
100 users
↓
Booking system
Ini fundamentally mengubah masalah.
Server booking tak perlu lagi survive "stampede".
Dia cuma perlu handle jumlah traffic yang kita memang izinkan masuk.
Tapi kalau nak custom waiting room?
Ini pun menarik.
Kalau aku nak bina sendiri, aku mungkin gunakan Redis.
Bukan sebab Redis itu magical.
Tapi sebab queue ialah state yang sangat sesuai diletakkan dalam fast in-memory datastore.
Contohnya:
queue:restaurant:2026-09-10
Dalam queue tu kita boleh simpan:
position
user/session
joined_at
status
admitted_at
Kemudian kita boleh buat admission control.
Contohnya sistem hanya membenarkan 50 atau 100 user masuk ke booking flow pada satu-satu masa.
Bila seorang selesai booking:
user selesai
↓
1 slot dibuka
↓
next user masuk
Dan UI waiting room boleh kita design sendiri.
Ini sebenarnya part yang aku rasa menarik.
Kita tak perlu buat waiting room yang nampak macam generic queue.
Boleh branding sepenuhnya ikut restoran.
Contohnya:
"Ramai yang sedang cuba mendapatkan meja malam ni."
"Anda sekarang di kedudukan 1,284."
"Anggaran masa menunggu: 8 minit."
Dan bila tiba giliran:
"You're in. Anda ada 10 minit untuk membuat reservation."
Aku tak perlu reinvent concept.
Aku cuma nak control admission ke booking system.
Queue sebenarnya bukan booking system
Ini satu perkara yang aku rasa penting.
Kalau aku buat sistem ni, aku akan asingkan:
Queue Engine
daripada
Reservation Engine.
Queue hanya jawab:
"Siapa yang boleh masuk sekarang?"
Reservation engine pula jawab:
"Apa yang boleh dia book?"
Ini dua masalah yang berbeza.
Architecture lebih kurang:
INTERNET
│
▼
┌──────────┐
│ Cloudflare│
└────┬─────┘
│
▼
┌────────────┐
│ QUEUE │
│ Redis │
└─────┬──────┘
│
Admission Token
│
▼
┌────────────┐
│ RESERVATION│
│ ENGINE │
└─────┬──────┘
│
▼
DATABASE
Dan Redis bukan source of truth untuk booking.
Database tetap source of truth.
Redis digunakan untuk benda yang perlukan speed:
- queue
- temporary lock
- session
- admission token
- rate limit
- temporary reservation state
Masalah kedua: Scalper
Ini yang lebih interesting.
Pada awalnya aku fikir:
"Identity."
Maybe kita boleh gunakan MyDigital ID.
Idea ni valid.
Kita tak perlu simpan IC 16 juta followers atau semua orang yang mungkin nak datang makan.
Itu pointless.
Kita hanya perlu verify identity apabila seseorang benar-benar sampai ke booking stage.
Contohnya:
Waiting Room
↓
Your turn
↓
Verify identity
↓
Create reservation
Dan sistem kita cuma perlu tahu:
Reservation ini dimiliki oleh siapa?
Bukan:
Simpan semua data 16 juta orang.
MyDigital ID memang menarik untuk use case identity/authentication kerana ia menyediakan mekanisme digital identity dan developer integration. Tetapi implementation sebenar untuk sesuatu commercial use case masih perlu tengok integration dan requirement yang tersedia pada masa sistem dibina.
Tapi kemudian aku fikir:
Identity sahaja tak solve scalping.
Sebab seorang manusia yang genuine pun boleh book untuk ramai orang.
Contohnya aku book 12 pax.
Boleh jadi:
- aku
- wife
- mak
- abah
- adik
- anak-anak
- mak saudara
- cousin
Itu normal.
Jadi kalau aku buat rule:
"Satu identity maksimum 4 pax."
Itu memang logic developer.
Tapi bukan logic dunia sebenar.
Aku tak nak sistem yang menghukum orang sebab dia nak bawa satu keluarga besar makan.
Jadi aku rasa kita kena solve masalah ni dengan cara lain.
Sebenarnya apa yang scalper jual?
Ini soalan yang bagi aku paling penting.
Scalper sebenarnya bukan jual makanan.
Dia cuba jual access to a scarce reservation.
Kalau reservation itu hanya:
Date
Time
Table
Pax
memang senang dijadikan komoditi.
Dia book.
Kemudian dia post:
"Rembayung 8 pax available. RM150/pax."
Dan pembeli datang.
Jadi aku cuba ubah apa sebenarnya yang berlaku apabila seseorang membuat booking.
Reservation bukan sekadar seating
Ini idea yang aku pernah gunakan sebelum ni.
Ramadhan reservation untuk Efa Western, flow reservation bukan:
Book table
↓
Done
Flow dia lebih kurang:
Choose date
↓
Choose pax
↓
Choose time
↓
Choose table
↓
Choose food
↓
Payment
↓
Reservation confirmed
Dan bagi aku, bahagian "choose food" tu sangat penting.
Table pun sebenarnya inventory
Dalam sistem Efa Western, selepas customer pilih tarikh dan jumlah pax, mereka akan masuk ke table selection.
Aku paparkan layout meja restoran.
Contohnya:
┌───────────┐
│ TABLE │
│ T01 │
│ 2 pax │
└───────────┘
┌───────────────┐ ┌───────────────┐
│ TABLE T02 │ │ TABLE T03 │
│ 4 pax │ │ 4 pax │
└───────────────┘ └───────────────┘
┌─────────────────┐
│ TABLE T04 │
│ 8 pax │
└─────────────────┘
Kalau customer pilih 2 pax, dia tak boleh pilih table 8 pax.
Bukan sebab aku nak buat arbitrary restriction.
Sebab table tu memang physical inventory.
Dan itu salah satu benda yang aku rasa software kena faham.
Restaurant bukan sekadar ada:
"200 seats."
Restaurant ada:
Table T01 Table T02 Table T03 Table T04 ...
Setiap table ada capacity.
Setiap table ada availability.
Setiap table ada time window.
Jadi reservation engine sebenarnya sedang mengurus physical inventory.
Contoh table layout yang pernah aku gunakan untuk sistem Efa Western.
Dan table selection perlu ada realtime locking
Bayangkan ada dua customer.
Customer A pilih Table T04.
Pada masa yang sama Customer B pun nampak Table T04 available.
Kalau tak ada locking:
Customer A → T04
Customer B → T04
💥 (BOOOM)
Jadi bila Customer A pilih table, aku akan lock table tersebut.
Contohnya:
T04
↓
LOCKED
↓
15–20 minutes
↓
Payment?
Kalau payment berjaya:
LOCKED
↓
BOOKED
Kalau customer abandon atau tak bayar:
LOCKED
↓
15–20 minutes expired
↓
AVAILABLE
Dan status tu boleh dihantar secara realtime melalui WebSocket.
Jadi customer lain nampak:
Table T04 baru sahaja diambil.
Tak perlu refresh page.
Tapi yang paling penting: order makanan upfront
Sekarang kita balik kepada masalah scalping.
Katakan seseorang berjaya book 16 pax.
Dia bukan sekadar dapat:
16 seats
Dia perlu membuat order.
Contohnya:
16 pax
8 × Chicken
4 × Steak
4 × Pasta
Drinks:
8 × Coke
4 × Tea
4 × Water
Kemudian dia membuat payment/deposit.
Sekarang reservation itu bukan lagi sekadar:
"Aku ada 16 seat."
Ia menjadi:
"Aku ada reservation untuk 16 orang pada waktu tertentu, di table tertentu, dengan order tertentu."
Itu jauh lebih susah untuk dijual semula sebagai commodity.
Kenapa?
Sebab scalper sekarang perlu cari buyer untuk:
seat + reservation + food commitment
Dan kalau dia cuba book banyak reservation, dia perlu keluarkan commitment yang lebih besar.
Kalau restoran mempunyai 200 seat dan dia cuba sapu 16 seat, dia mungkin perlu commit kepada makanan untuk 16 orang.
Kalau dia cuba buat 5 booking?
Sekarang dia bukan sekadar "pegang seat".
Dia pegang inventory restoran yang mempunyai monetary commitment.
Ini mengubah economics scalping.
Tapi legitimate customer masih boleh book 16 pax
Ini bahagian yang aku suka tentang model ni.
Aku tak perlu cakap:
"Maximum 4 pax."
Aku boleh benarkan 2, 4, 8, 12, 16 pax bergantung kepada capacity restoran.
Kalau seseorang memang nak bawa satu keluarga besar, silakan.
Contohnya:
Faiz
12 pax
Table: T08
Pre-order:
- 6 Chicken
- 3 Steak
- 3 Pasta
No problem.
Identity hanya menentukan:
Siapa pemilik reservation?
Pax pula menentukan:
Berapa ramai orang yang akan datang?
Food order menentukan:
Apa yang restoran perlu prepare?
Ini tiga benda berbeza.
Dan ini juga bagus untuk restoran
Ini sebenarnya side effect yang sangat menarik.
Bila customer order makanan upfront, restaurant dapat data sebelum customer datang.
Contohnya untuk esok:
12:00
24 Chicken
12 Steak
8 Pasta
Drinks:
20 Coke
10 Tea
14 Water
Kitchen boleh prepare berdasarkan actual booking.
Restaurant tak perlu hanya agak-agak:
"Esok mungkin ramai."
Mereka dah ada demand signal.
Ini boleh membantu dari segi:
- ingredient preparation
- purchasing
- kitchen preparation
- manpower planning
- food waste
- stock planning
Jadi feature yang asalnya nampak macam anti-scalping sebenarnya juga merupakan restaurant operation feature.
Lepas customer sampai, baru extra order
Aku tak rasa kita perlu lock customer kepada makanan yang mereka pre-order.
Customer sampai.
Makan.
Kemudian:
"Eh, tambah satu steak."
No problem.
Scan QR.
Order lagi.
Atau panggil staff.
Staff masukkan order.
Dan customer bayar balance.
Contohnya:
Pre-order
Food RM480
Drinks RM120
-----------------------
Subtotal RM600
Deposit RM200
Balance RM400
Kemudian customer tambah:
Extra food RM80
Extra drinks RM20
-----------------------
Additional RM100
Final balance:
RM400 + RM100
= RM500
Simple.
Jadi flow penuh sistem tu nampak macam ni
CUSTOMER
│
▼
┌─────────────┐
│ WAITING ROOM│
└──────┬──────┘
│
▼
┌─────────────┐
│ IDENTITY │
└──────┬──────┘
│
date + pax
│
▼
┌─────────────┐
│ TABLE ENGINE│
│ │
│ availability│
│ capacity │
│ realtime lock│
└──────┬──────┘
│
table locked
│
▼
┌─────────────┐
│ PRE-ORDER │
│ │
│ food │
│ drinks │
└──────┬──────┘
│
▼
PAYMENT
│
▼
RESERVATION
CONFIRMED
│
▼
CUSTOMER ARRIVES
│
▼
┌─────────────┐
│ EXTRA ORDER │
│ QR / STAFF │
└──────┬──────┘
│
▼
FINAL BILL
Dan setiap layer menyelesaikan masalah yang berbeza.
Jadi macam mana dua masalah Rembayung tadi diselesaikan?
1. Website crash
Waiting Room.
Tak kisah sama ada:
- Cloudflare Waiting Room
- custom Redis queue
- atau combination kedua-duanya
Konsepnya sama.
Jangan benarkan ribuan orang masuk ke booking application pada masa yang sama.
Control admission.
2. Scalper sapu seat
Jangan jadikan seat itu standalone commodity.
Booking perlu ada:
Identity
+
Date
+
Time
+
Table
+
Pax
+
Pre-order
+
Payment
Reservation owner boleh bawa keluarga atau kawan.
Tak perlu paksa setiap seorang verify identity.
Tapi reservation itu sendiri ada owner dan ada commercial commitment.
Dan sebenarnya aku tak perlu cuba "hapuskan" scalper
Ini satu lagi perkara yang aku rasa penting.
Software tak semestinya boleh menghapuskan scalping 100%.
Kalau seseorang book 16 pax, bayar semuanya, kemudian dia sendiri datang ke restoran bersama 16 orang yang membayar dia secara offline...
Secara teknikal, macam mana sistem nak tahu itu keluarga dia atau customer yang dia jual?
Tak boleh.
Sistem tak boleh baca niat manusia.
Jadi objective yang lebih realistic ialah:
Make scalping difficult and unattractive to scale.
Bukan:
"Pastikan tiada seorang pun boleh scalping."
Itu dua benda yang berbeza.
Aku rasa identity masih berguna
Identity tetap penting.
Cuma identity bukan magic anti-scalping solution.
Identity berguna untuk menentukan:
Siapa yang membuat reservation?
Siapa yang bertanggungjawab terhadap reservation?
Siapa yang perlu hadir?
Kalau perlu, masa check-in kita boleh verify reservation owner.
Jadi reservation bukan sesuatu yang boleh dengan mudah dipindahkan sesuka hati.
Customer masih boleh bawa orang lain.
Tapi ownership reservation kekal pada booking owner.
Apa yang menarik tentang semua ni?
Bagi aku, ini contoh yang baik kenapa software engineering bukan sekadar:
"Nak guna Laravel ke Node?"
atau
"Redis ke MySQL?"
atau
"Cloudflare ke AWS?"
Semua tu penting.
Tapi sebelum pilih technology, kita kena faham business problem yang sebenarnya berlaku.
Dalam case ni:
Problem #1
Ramai orang datang serentak.
Solution:
Control traffic.
Problem #2
Inventory yang terhad boleh menjadi commodity untuk resale.
Solution:
Ubah model reservation supaya reservation datang bersama dining commitment.
Problem #3
Restaurant perlu tahu apa yang perlu disediakan.
Solution:
Pre-order.
Problem #4
Table ialah physical inventory yang tak boleh ditempah dua orang.
Solution:
Realtime table locking.
Problem #5
Customer mungkin nak tambah makanan.
Solution:
Extra ordering selepas customer sampai.
Dan tiba-tiba kita tak lagi bercakap tentang "booking system".
Kita sebenarnya sedang design satu sistem yang menggabungkan:
Traffic Management
+
Identity
+
Reservation
+
Inventory
+
Table Management
+
Food Ordering
+
Payment
+
Restaurant Operations
Itu yang bagi aku lebih menarik.
Kalau aku nak bina benda ni sekarang
Aku mungkin tak akan terus start coding.
Aku akan pecahkan architecture dulu.
CLOUDFLARE
│
┌─────────┴─────────┐
│ │
WAF WAITING ROOM
│
REDIS QUEUE
│
▼
ADMISSION TOKEN
│
▼
RESERVATION API
│
┌────────────────┼────────────────┐
│ │ │
▼ ▼ ▼
IDENTITY TABLES MENU
│ │ │
│ REALTIME LOCK │
│ │ │
└────────────────┼────────────────┘
│
▼
ORDER
│
▼
PAYMENT
│
▼
RESERVATION
│
▼
RESTAURANT SYSTEM
│
┌─────────────┴─────────────┐
▼ ▼
KITCHEN CHECK-IN
│ │
▼ ▼
PREPARE ORDER EXTRA ORDER
│
▼
FINAL PAYMENT
Aku akan guna database relational sebagai source of truth.
Redis untuk benda yang perlukan high-speed temporary state.
WebSocket untuk realtime availability.
Cloudflare untuk edge protection.
Waiting room untuk admission control.
Identity provider untuk verification.
Dan reservation engine sebagai pusat yang bind semuanya.
Kesimpulan
Bila tengok balik kes Rembayung, aku rasa dua masalah yang berlaku tu sebenarnya bukan satu masalah besar. Cuma kritikal untuk operasi.
Ia dua masalah yang berbeza.
Website crash bukan masalah booking.
Ia masalah traffic admission.
Dan scalping bukan semata-mata masalah identity.
Ia masalah bagaimana reservation itu direka sebagai sebuah product/inventory.
Aku boleh buat waiting room untuk memastikan 3,000 orang tak menghentam server pada masa yang sama.
Aku boleh gunakan identity verification supaya reservation mempunyai owner yang jelas.
Tapi untuk scalping, aku tak perlu cuba buat sistem yang menentukan:
"Orang ni scalper atau bukan?"
Aku boleh design reservation supaya:
seat datang bersama table, time slot, food order dan payment commitment.
Dan sebenarnya aku dah pernah buat sebahagian daripada konsep ni untuk Efa Western.
Bezanya, masa tu scale traffic bukan masalah.
Reservation dibuka untuk tarikh tertentu, customer pilih pax, pilih table berdasarkan layout sebenar restoran, table akan di-lock sementara sebelum payment, kemudian customer pre-order makanan.
Bagi restaurant, ini bukan sahaja membantu reservation.
Restaurant juga boleh tahu lebih awal apa yang perlu disediakan.
Jadi kalau satu hari nanti aku kena design sistem booking untuk restoran yang tiba-tiba menjadi viral, aku tak akan bermula dengan soalan:
"Server nak guna apa?"
Aku akan mula dengan:
"Apa sebenarnya yang kita nak kawal?"
Traffic?
Control admission.
Table?
Lock inventory.
Identity?
Verify ownership.
Scalping?
Jangan jadikan reservation sekadar seat.
Restaurant operation?
Collect the order upfront.
Bila kita pecahkan masalah macam ni, architecture biasanya jadi jauh lebih jelas.
Dan teknologi pula tinggal pilih tool yang paling sesuai untuk menyelesaikan setiap masalah tersebut.
