Design Ticketmaster

Prompt latihan

1. Problem Statement, Functional Requirements, and Scale Assumptions

   Tentukan ruang lingkup platform pemesanan tiket: pengguna menjelajahi event (konser, olahraga, teater), melihat kursi yang tersedia pada peta kursi, memilih kursi, dan menyelesaikan checkout untuk membeli tiket. Sistem harus menegakkan bahwa tidak ada dua pengguna yang dapat membeli kursi yang sama untuk event yang sama. Kecualikan secara eksplisit pembuatan event dan manajemen venue (ditangani oleh tool admin terpisah), marketplace jual-ulang, algoritma dynamic pricing, dan SDK pembayaran aplikasi mobile dari desain awal. Nyatakan asumsi skala awal (event yang terdaftar kapan saja, sesi checkout bersamaan puncak saat on-sale populer, tiket terjual per detik saat puncak) sebelum mengusulkan komponen apa pun.

2. Non-Functional Requirements

   Tentukan NFR utama: konsistensi ketersediaan kursi (dua pengguna tidak boleh membeli kursi yang sama, ini adalah kebutuhan hard consistency, bukan eventual), waktu tahan reservasi (kursi yang dipilih tetapi belum dibayar harus direservasi selama N menit agar pengguna dapat menyelesaikan checkout), rasio baca:tulis saat browse vs. on-sale (browsing bersifat read-heavy; momen on-sale menciptakan lonjakan tulis ekstrem saat ribuan pengguna mencoba checkout bersamaan), dan idempotensi pembelian tiket (pengguna mengklik 'Buy' dua kali tidak boleh membuat dua order).

3. Quantitative Analysis

   Estimasikan QPS browse puncak (event × kursi per event × tampilan per peta kursi pada kondisi tunak), QPS checkout puncak saat waktu on-sale (konser populer dengan 50 ribu kursi terjual habis dalam 10 menit, berapa QPS percobaan checkout puncak?), update baris reservasi kursi per detik saat puncak, dan laju kontensi (rasio percobaan checkout terhadap kursi yang tersedia). Identifikasi lonjakan on-sale sebagai event trafik non-linear yang memerlukan strategi penskalaan berbeda dari trafik browse kondisi-tunak.

4. API Design

   Tentukan operasi API untuk mencari event, mengambil peta kursi untuk sebuah event (dengan status ketersediaan per kursi), mereservasi kursi (tahan durasi-pendek), menyelesaikan checkout (mengonversi reservasi menjadi pembelian terkonfirmasi), dan melepas reservasi (eksplisit atau saat TTL kedaluwarsa). Sertakan siklus hidup reservasi (available → reserved → purchased atau released), idempotency key untuk checkout, dan bagaimana response peta kursi mengomunikasikan status kursi (available, direservasi oleh saya, direservasi oleh orang lain, sold).

5. High-Level Design

   Usulkan komponen utama: event/venue service (katalog event, data peta kursi), seat availability service (membaca ketersediaan saat ini, harus sangat konsisten), reservation service (membuat tahan kursi durasi-pendek), checkout service (memproses pembayaran dan memfinalisasi tiket), dan job latar belakang untuk melepas reservasi yang kedaluwarsa. Jelaskan bagaimana keunikan kursi ditegakkan (optimistic locking, pessimistic locking, atau distributed lock) dan di mana state kursi dipersistensi.

6. Additional High-Level Design Prompts

   Bahas tiga area lanjutan: (1) Virtual waiting room, bagaimana menangani lonjakan on-sale saat 100 ribu pengguna secara bersamaan mencoba mengakses peta kursi untuk konser populer sebelum tiket dijual (admission berbasis antrian sehingga hanya N pengguna masuk alur reservasi pada satu waktu); (2) Pembuatan PDF tiket, bagaimana tiket digital (dengan kode QR untuk pemindaian venue) dibuat dan dikirim ke pembeli setelah pembelian; (3) Penanganan kegagalan parsial, jika pembayaran berhasil tetapi pembuatan record tiket gagal, bagaimana memastikan pembeli mendapat tiketnya dan kursi tidak dibiarkan dalam state reserved-tetapi-belum-dibayar.

7. Deep Dives

   Deep dive ke tiga area: (1) Konsistensi reservasi kursi, optimistic locking: baca baris kursi, cek status=available, tulis status=reserved dengan pengecekan versi (gagal jika penulis lain memenangkan balapan); pessimistic locking: SELECT FOR UPDATE pada baris kursi selama transaksi reservasi (menserialkan penulis tetapi mengurangi throughput); distributed lock (Redis Redlock): berguna saat reservation service stateless tetapi menambah network hop; bandingkan ketiganya untuk kebenaran dan throughput pada 1.000 checkout bersamaan untuk event yang sama; (2) TTL dan kedaluwarsa reservasi, tahan reservasi berlangsung 5–10 menit; diimplementasikan sebagai baris database dengan field expires_at; job latar belakang (cron atau event-driven) men-query reservasi yang kedaluwarsa dan mentransisikannya kembali ke available; race condition: jika job latar belakang dan checkout baru terjadi bersamaan untuk kursi yang sama, mana yang menang? Gunakan UPDATE kondisional WHERE status='reserved' AND expires_at < NOW(); (3) Peta kursi pada skala besar, untuk stadion 50 ribu-kursi, mengambil semua status ketersediaan kursi secara real-time untuk 10 ribu pengguna bersamaan itu mahal; strategi: cache peta kursi di Redis dengan TTL pendek (1-2 detik), terima sedikit kebasian saat browse, tegakkan konsistensi hanya saat reservasi.

8. Final Review Handoff Readiness

   Ringkas keputusan desain utama: mekanisme konsistensi reservasi kursi (optimistic atau pessimistic locking), job TTL dan kedaluwarsa reservasi, strategi caching peta kursi, virtual waiting room untuk lonjakan on-sale, dan atomisitas pembayaran + pembuatan tiket (pola saga). Soroti dua pertanyaan terbuka terbesar yang tersisa (throughput strategi locking saat kontensi ekstrem, berapa banyak checkout bersamaan yang dapat ditangani reservation service, dan keadilan antrian waiting room, FIFO vs. admission acak) dan usulkan rollout bertahap: browse + peta kursi dulu, lalu reservasi + checkout, lalu waiting room.

Preview solusi

Solusi Referensi, Merancang Ticketmaster Inti Wawasan Tantangan utama Ticketmaster adalah keunikan seat (kursi) di bawah write dengan contention tinggi . Dua pengguna tidak boleh pernah membeli seat yang sama, namun pada saat on-sale ribuan pengguna mencoba checkout secara bersamaan. Keseluruhan desain mengalir dari constraint ini. Functional Requirements (D…