Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
Bu yazıda bir “ticket booking” (bilet satın alma) sisteminin nasıl tasarlandığını adım adım öğreneceksin. Ama sadece ne yapıldığını değil, neden öyle yapıldığını da anlayacaksın. Özellikle sistem design mülakatlarında nasıl düşünmen gerektiğini net şekilde kafanda oturtacaksın.
Sistem Design’a Nasıl Başlanır?
Şimdi şöyle bir düşün… Sana “Ticketmaster benzeri bir sistem tasarla” deniyor. Çoğu kişi direkt teknik çözüm üretmeye atlar. Ama bu yanlış.
Doğru yaklaşım şu sırayı takip etmek:
- Gereksinimleri anlamak
- Veriyi (entity) belirlemek
- API’leri tanımlamak
- Basit bir mimari kurmak
- Sonra derinlemesine iyileştirmek
Bu aslında bir framework.
Yani şöyle düşün:
Evi yapmadan önce plan çizmek gibi. Direkt duvar örmeye başlarsan, ortasında pencereyi nereye koyacağını düşünmek zorunda kalırsın.
Sistemin Temel Özellikleri (Functional Requirements)
Bir sistemin ne yapacağını tanımlamakla başlıyoruz.
Ticket sistemi için en kritik 3 şey var:
- Kullanıcı etkinlik arayabilmeli
- Kullanıcı etkinliği görüntüleyebilmeli
- Kullanıcı bilet satın alabilmeli
Aslında bu bir kullanıcı akışı:
Search → Event Page → Ticket Booking
Bunu şöyle hayal edebilirsin:
Google’da konser arıyorsun → etkinliğe giriyorsun → koltuk seçip satın alıyorsun.
Sistem Kalitesi (Non-Functional Requirements)
Burada çoğu kişi hata yapıyor.
“Scalability”, “availability” yazıp geçmek yetmez. Önemli olan bu sistemde neden önemli oldukları.
Consistency vs Availability
Bu sistemde en kritik karar:
- Aynı koltuk iki kişiye satılmamalı → Consistency önemli
- Ama arama ve sayfa görüntüleme hızlı olmalı → Availability önemli
Yani şöyle düşün:
Bir konser koltuğunu iki kişiye satarsan sistem çöker. Ama bir etkinliği 2 saniye geç görmek sorun değil.
Read vs Write Oranı
Bu sistemde:
- Okuma (search, view) >> Yazma (booking)
Bunu şöyle hayal edebilirsin:
100 kişi etkinliğe bakar, belki 1 kişi satın alır.
Trafik Patlamaları (Traffic Spikes)
Normalde sistem sakin çalışır ama:
- Büyük konserler
- Dünya kupası
- Popüler etkinlikler
bir anda milyonlarca kullanıcı getirir.
Yani şöyle düşün:
Site normalde boş bir AVM gibi. Ama indirim günü herkes kapıya yığılır.
Temel Veri Yapıları (Core Entities)
Sistemde hangi veriler var?
- Event (Etkinlik)
- Venue (Mekan)
- Performer (Sanatçı)
- Ticket (Bilet)
En kritik olan: Ticket
Çünkü:
- Satıldı mı?
- Rezerve mi?
- Hangi kullanıcıya ait?
API Tasarımı
Sistemle kullanıcı nasıl konuşuyor?
1. Event Görüntüleme
GET /events/{eventId}
Event + koltuk bilgileri döner.
2. Event Arama
GET /search?term=&location=&date=
Kısa bilgiler döner.
3. Ticket Booking (En Kritik Kısım)
Bu 2 aşamalı:
1. Reserve (Ayırma)
POST /reserve
2. Confirm (Satın alma)
POST /confirm
Bunu şöyle hayal edebilirsin:
Koltuk seçiyorsun → 10 dakika sana ayrılıyor → ödeme yapıyorsun.
Yüksek Seviye Mimari (High-Level Design)
Temel yapı şöyle:
Client → API Gateway → Microservices → Database
API Gateway
- Request yönlendirir
- Authentication yapar
- Rate limit uygular
Yani şöyle düşün:
AVM girişindeki güvenlik görevlisi gibi.
Microservices
- Event Service
- Search Service
- Booking Service
Her biri farklı iş yapar.
Database
Genelde SQL tercih edilir (örneğin PostgreSQL)
Sebep:
- Transaction desteği
- Veri tutarlılığı
Ticket Reservation Problemi (Kritik Nokta)
Şimdi önemli bir problem:
Kullanıcı koltuğu seçti ama ödeme yapmadı.
Ne olacak?
Yanlış çözüm:
- DB’ye “reserved” yazmak
Sorun:
Kullanıcı çıkarsa koltuk sonsuza kadar kilitli kalır.
Cron Job Yaklaşımı
Belirli aralıklarla:
- Süresi dolan rezervleri temizler
Ama sorun:
- 10 dakika yerine 19 dakika kilitli kalabilir
Doğru Çözüm: Distributed Lock (Redis)
Ticket rezervlerini DB yerine cache’te tutarız.
ticketId → locked (TTL: 10 dakika)
Yani şöyle düşün:
Koltuk üstüne “rezerve” etiketi koyuyorsun ama 10 dakika sonra otomatik düşüyor.
Avantaj:
- Gerçek zamanlı
- Temiz ve hızlı
Arama Performansı Problemi
SQL ile arama:
- Yavaş (full scan)
Çözüm: Elasticsearch
Nasıl çalışır?
Metni parçalar ve index oluşturur.
Bunu şöyle hayal edebilirsin:
Kitabın sonunda kelime indeksi var ya, aynısı.
Trafik Patlaması Çözümü: Waiting Queue
Milyon kişi aynı anda gelirse?
Çözüm: Virtual Queue
Users → Queue → Sisteme giriş
Yani şöyle düşün:
Konser bileti için sıraya giriyorsun.
Avantaj:
- Sistemi korur
- Kullanıcı deneyimini iyileştirir
Gerçek Zamanlı Seat Güncelleme
Koltuklar hızlı değişir.
Çözüm:
- Long Polling
- SSE (Server-Sent Events)
Bunu şöyle hayal edebilirsin:
Sayfayı yenilemeden koltuklar anlık güncelleniyor.
Özet
Aslında bu sistemin özü çok net:
Önce neyi çözdüğünü anlaman gerekiyor. Kullanıcı ne yapıyor, nerede zorlanır, sistem nerede kırılır… Bunları doğru analiz ettiğinde teknik çözüm zaten doğal olarak geliyor.
Ticket sistemi özelinde en kritik noktalar şunlar:
Biletin iki kişiye satılmaması için güçlü bir tutarlılık sağlamak, milyonlarca kullanıcının aynı anda sisteme yüklenmesini yönetmek ve kullanıcıya gerçek zamanlı, doğru bilgi göstermek. Bunun için de basit ama doğru araçlar kullanılıyor: cache, queue, search engine ve distributed lock gibi.
Yani olay aslında teknoloji değil, doğru yerde doğru problemi çözmek.
Bu yazı Designing a Ticket Booking Service (System Design Interview) videosundan ilham alınarak yazılmıştır.
