Wawancara koding: Merancang modul reservasi meja restoran

Prompt dan konteks yang sesuai

Ini adalah pertanyaan desain tingkat rendah (low-level design) dan koding. Tujuannya adalah mengubah reservasi, meja, interval waktu, dan daftar tunggu menjadi objek dengan tanggung jawab yang jelas. Laporan wawancara publik telah mencakup desain reservasi restoran, sementara panduan OOD menekankan untuk memperjelas cakupan, mendaftar persyaratan, lalu memilih objek dan antarmuka. Asumsikan satu restoran, jam buka tetap, dan modul dalam memori (in-memory); tambahkan persistensi dan kontrol konkurensi jika pewawancara memintanya.

Apa yang dinilai oleh pewawancara

• Apakah Anda memisahkan Restaurant, Table, Reservation, Waitlist, dan kebijakan alokasi.
• Apakah Anda menangani interval setengah terbuka (half-open), kapasitas, penggabungan meja, dan pelepasan setelah pembatalan dengan benar.
• Apakah Anda merancang state machine, permintaan idempoten, dan tidak adanya penugasan ganda di bawah konkurensi.
• Apakah pengujian mencakup kasus batas dan Anda dapat menjelaskan kompleksitas serta titik ekstensi.

Klarifikasi yang perlu ditanyakan terlebih dahulu

Tanyakan apakah tamu memilih meja tertentu atau hanya jumlah tamu, dan apakah meja boleh digabungkan. Perjelas durasi reservasi dan buffer pembersihan, pengeditan, keterlambatan, ketidakhadiran (no-show), pelanggan walk-in, urutan daftar tunggu, dan percobaan ulang permintaan. Konfirmasikan presisi waktu, zona waktu, satu versus banyak restoran, dan apakah diperlukan persistensi lintas proses.

Kerangka jawaban 30 detik

Pertama, saya akan mendefinisikan TimeRange yang immutable dan state machine reservasi. AvailabilityService menangani kueri konflik, TableAllocator memilih berdasarkan kapasitas dan kebijakan, ReservationService mengorkestrasi pembuatan, pembatalan, dan notifikasi, serta Waitlist mengelola kandidat secara terpisah. Pembuatan menggunakan kunci idempotensi dan memeriksa ulang ketersediaan di dalam critical section yang sama sebelum menempati meja. Pembatalan hanya mengizinkan transisi yang valid dan melepaskan kapasitas. Pengujian mencakup interval yang berdekatan, permintaan konkuren, pembatalan berulang, dan promosi daftar tunggu.

Jawaban mendalam langkah demi langkah

1. Memodelkan waktu, meja, dan status reservasi

Representasikan reservasi dengan interval setengah terbuka [start, end), yang memerlukan start < end. Dua interval tumpang tindih ketika a.start < b.end && b.start < a.end. Table menyimpan kapasitas, pengenal, dan ketersediaan; Reservation menyimpan tamu, ukuran rombongan, interval, meja, dan status. Status dapat berupa HELD, CONFIRMED, SEATED, CANCELLED, dan NO_SHOW; tolak transisi yang tidak valid.

2. Membuat alokasi dapat diganti

TableAllocator menerima meja kandidat dan sebuah permintaan. Secara default, sistem memilih meja terkecil yang muat untuk menghindari pemborosan; kebijakan lain dapat memprioritaskan meja yang berdekatan atau aksesibilitas. Alokator tidak menulis reservasi, menjaga pencarian, keputusan, dan persistensi tetap terpisah alih-alih membuat satu kelas raksasa.

3. Mengimplementasikan pemeriksaan konflik dan pembuatan

Filter berdasarkan restoran, interval, dan indeks meja, lalu biarkan alokator memilih. Pembuatan memvalidasi input, menerapkan buffer pembersihan, membuat kunci idempotensi, dan membaca ulang ketersediaan di dalam satu kunci (lock) atau transaksi sebelum menulis. Sistem tidak boleh mempercayai hasil pencarian yang sudah usang. Invariannya eksplisit: satu meja memiliki nol reservasi CONFIRMED yang tumpang tindih.

create(request, key):
  if idempotency.exists(key): return idempotency.result(key)
  range = TimeRange(request.start, request.end + cleanupBuffer)
  lock(restaurantId, range):
    table = allocator.choose(availableTables(range), request.partySize)
    if table is null: return WAITLISTED
    reservation = Reservation.confirm(request, table, range)
    store(reservation)
    idempotency.save(key, reservation.id)
    return reservation

4. Menangani pembatalan, keterlambatan, dan promosi

Pembatalan hanya mengizinkan HELD atau CONFIRMED untuk menjadi CANCELLED; mengulanginya akan mengembalikan hasil yang sama dan tidak menduplikasi notifikasi. Kedatangan mengubah status menjadi SEATED; batas waktu kebijakan dapat menjadikannya NO_SHOW dan melepaskan meja. WaitlistMatcher mengonsumsi event pelepasan, mencocokkan berdasarkan waktu tunggu, ukuran rombongan, dan prioritas, lalu menggunakan kembali critical section pembuatan yang sama sehingga pemesanan baru tidak dapat menetapkan meja secara ganda.

5. Menguji dan menjelaskan kompleksitas

Uji bahwa interval [19:00,20:00) dan [20:00,21:00) yang berdekatan tidak berkonflik, input terbalik ditolak, pembersihan memperluas cakupan konflik, kunci idempotensi yang berulang tidak membuat reservasi ekstra, pembatalan mempromosikan paling banyak satu kali, dan pembuatan konkuren hanya memiliki satu pemenang. Jika setiap meja menyimpan reservasi yang terurut, pencarian konflik untuk satu meja adalah O(log n + k); dengan m meja kandidat, pemilihan dan penulisan adalah sekitar O(m log n). Bucket kapasitas atau indeks interval dapat meningkatkannya.

Contoh jawaban berkualitas tinggi

Saya akan memodelkan TimeRange setengah terbuka yang immutable, state machine reservasi yang eksplisit, dan kebijakan alokasi yang dapat diganti. AvailabilityService memfilter berdasarkan restoran, waktu, dan meja; TableAllocator memilih meja terkecil yang memadai; ReservationService membaca ulang dan menulis di dalam satu kunci atau transaksi menggunakan kunci idempotensi. Pembatalan, keterlambatan, dan ketidakhadiran melepaskan kapasitas melalui transisi yang valid, dan pencocokan daftar tunggu menggunakan kembali critical section yang sama. Pengujian mencakup interval yang berdekatan, buffer pembersihan, pembatalan berulang, pembuatan konkuren, dan race condition pada daftar tunggu, dengan kompleksitas terindeks yang dinyatakan.

Kesalahan umum

• Menempatkan semua logika dalam Restaurant dengan tanggung jawab dan penggantian kebijakan yang tidak jelas.
• Menggunakan interval tertutup dan salah menandai reservasi yang bersebelahan sebagai konflik.
• Mencari ketersediaan dan menulis kemudian tanpa memeriksa ulang pada batasan penulisan.
• Membuat pembatalan tidak idempoten sehingga percobaan ulang melepaskan meja atau memberi notifikasi dua kali.
• Hanya mengimplementasikan pemesanan tamu sambil mengabaikan walk-in, keterlambatan, no-show, dan daftar tunggu.
• Hanya menampilkan diagram kelas tanpa invarian, pengujian batas, atau kompleksitas.

Pertanyaan lanjutan dan tanggapan

Bagaimana Anda akan mendukung meja yang digabungkan?

Mengembalikan kumpulan meja yang berurutan daripada satu tableId, menambahkan batasan untuk total kapasitas, keterhubungan, dan konflik di seluruh kumpulan meja. Pertahankan antarmuka alokator dan tambahkan implementasi ComposableTableAllocator.

Bagaimana Anda mencegah pemesanan ganda lintas proses?

Pindahkan invarian konflik ke persistensi dengan kunci yang dapat diverifikasi atau batasan transaksional pada meja dan waktu. Kunci aplikasi dapat mengurangi pertentangan (contention) tetapi tidak dapat menjadi satu-satunya jaminan kebenaran.

Bagaimana jika pengguna mengklik buat berulang kali?

Wajibkan kunci idempotensi klien dan simpan hasilnya berdasarkan cakupan restoran dan pengguna. Kunci yang sama mengembalikan reservasi awal; kunci yang berbeda tetap melalui pemeriksaan konflik bersama. Pembatasan laju (rate limiting) bukanlah pengganti idempotensi bisnis.

Bagaimana Anda mengoptimalkan slot makan malam yang populer?

Lakukan sharding berdasarkan restoran dan waktu. Gunakan cache hanya untuk petunjuk pencarian; pembuatan akhir tetap berada dalam critical section yang konsisten secara ketat. Bucket kapasitas yang telah dihitung sebelumnya dan kandidat daftar tunggu masih memerlukan pemeriksaan versi sebelum menulis.

Bagaimana jika notifikasi gagal setelah pembatalan?

Lakukan commit untuk perubahan status dan event outbox dalam satu transaksi; buat konsumen notifikasi idempoten dan dapat dicoba ulang. Pelepasan meja tidak boleh menunggu keberhasilan SMS; kegagalan masuk ke antrean percobaan ulang dan dead-letter queue yang terlihat oleh operator.