Studi Kasus: Membangun Sistem Pemesanan Tiket dengan gRPC

Selamat datang di perjalanan arsitektural membangun sistem distribusi tiket yang scalable dan efisien. Di artikel kali ini, saya akan membedah rancangan dan implementasi microservice pemesanan tiket menggunakan gRPC, mulai dari konsep hingga contoh kode siap pakai.

Latar Belakang: Ketika HTTP REST Mulai Terbatas

Sebagai engineer, sering kali kita bertemu batas-batas performa HTTP REST. Ketika organisasi tumbuh, lalu lintas API kian meningkat, kebutuhan real-time meningkat, atau layanan bertambah semakin kompleks, solusi RPC (Remote Procedure Call) seperti gRPC menjadi sangat menarik. gRPC, lahir dari dapur Google, menawarkan efisiensi, performa, dan kemampuan komunikasi service-to-service yang jauh lebih baik ketimbang protokol REST tradisional.

Studi Kasus: Sistem Pemesanan Tiket Event

Bayangkan Anda membangun sistem pemesanan tiket digital. Dalam arsitektur microservice, komponen utama yang dibutuhkan antara lain:

1. Service Pemesanan: Menerima permintaan pesanan, mengelola pembayaran sementara.
2. Service Inventaris: Menyimpan sisa tiket, melakukan pengurangan stok secara atomic.
3. Service Notifikasi: Memberi tahu pelanggan via email/WA/Push ketika booking berhasil.
4. Service Auth: Mengelola otorisasi pengguna.

Untuk studi kasus ini, kita akan mengintegrasikan microservice 1 dan 2 menggunakan gRPC.

Memahami Flow Sistem

Agar proses pemesanan efisien dan konsisten antarlayanan, berikut flowchart-nya:

graph TD
    A[Client] -->|Book Ticket| B(Pemesanan Service)
    B --> |Check & Lock Ticket| C(Inventaris Service)
    C --> |OK| B
    B --> |Confirmed| A
    B --> |Failed| A

Tabel berikut mendetailkan alur tiap langkah:

Definisi Proto File: gRPC Ticketing

Komunikasi antarlayanan menggunakan gRPC memanfaatkan .proto file untuk mendefinisikan contract. Sederhana saja, cukup dua method utama: Cek & Kunci tiket.

syntax = "proto3";

package ticketing;

service InventoryService {
  rpc CheckAndLock (TicketRequest) returns (TicketResponse) {}
}

message TicketRequest {
  string event_id = 1;
  int32 quantity = 2;
}

message TicketResponse {
  bool success = 1;
  string message = 2;
}

• CheckAndLock: Memastikan tiket tersedia dan menguncinya untuk sementara waktu.

Implementasi Singkat (Golang)

1. Inventory Service

// inventory_service.go
type InventoryServiceServer struct {
    mu sync.Mutex
    tickets map[string]int // eventID -> sisa tiket
}

func (s *InventoryServiceServer) CheckAndLock(ctx context.Context, req *pb.TicketRequest) (*pb.TicketResponse, error) {
    s.mu.Lock()
    defer s.mu.Unlock()

    stock := s.tickets[req.EventId]
    if stock < int(req.Quantity) {
        return &pb.TicketResponse{Success: false, Message: "Not enough tickets"}, nil
    }
    s.tickets[req.EventId] -= int(req.Quantity)
    return &pb.TicketResponse{Success: true, Message: "Locked"}, nil
}

2. Order Service (Client gRPC)

// order_service.go
conn, _ := grpc.Dial("inventaris:50051", grpc.WithInsecure())
client := pb.NewInventoryServiceClient(conn)

resp, err := client.CheckAndLock(ctx, &pb.TicketRequest{
    EventId: "EVT123",
    Quantity: 2,
})

if err != nil || !resp.Success {
    // handle gagal booking
}

Simulasi Multi-Client: Masalah Race Condition

Tantangan besar aplikasi tiket adalah race condition (dua orang checkout tiket yang sama secara hampir bersamaan). Berikut simulasi sederhana (psuedocode):

go func() {
    // Client A
    client.CheckAndLock(ctx, TicketRequest{EventId: "EVT123", Quantity: 2})
}()
go func() {
    // Client B
    client.CheckAndLock(ctx, TicketRequest{EventId: "EVT123", Quantity: 2})
}()

Pada InventoryService, penguncian stok dengan mutex (mu.Lock()) menjaga supaya proses atomic dan tidak terjadi overselling.

Kelebihan gRPC di Sistem Tiketing

1. Performance: gRPC menggunakan Protobuf yang lebih cepat dan hemat bandwidth.
2. Bilateral Streaming: Mendukung streaming dua arah, berguna untuk notifikasi real-time kepada client.
3. Contract First API: Validasi via proto membuat integrasi lebih disiplin, error antar service turun drastis.
4. Polyglot Friendly: Order dari backend Go, inventaris dari Java, notifikasi Python? Semua bisa karena gRPC punya banyak binding.

Bandingkan Performa: REST vs gRPC

Realita di Lapangan: Skenario Partial Failure & Retries

gRPC menawarkan fitur deadline dan retrier untuk mengatasi permintaan yang gagal secara otomatis—fitur ini sangat relevan di sistem pesanan tiket yang butuh SLA tinggi.

ctx, cancel := context.WithTimeout(context.Background(), 1*time.Second)
defer cancel()

_, err := client.CheckAndLock(ctx, &pb.TicketRequest{...})
if grpc.Code(err) == codes.DeadlineExceeded {
    // retry logic
}

Tips Engineering gRPC Ticket System

1. Timeout & Retry: Selalu set strategi retry. Jangan biarkan client menunggu tanpa batas.
2. Distributed Lock: Untuk skala besar, gunakan distributed lock (misal Redis redlock) agar stok di banyak replica tetap konsisten.
3. Observability: Manfaatkan intersepctor gRPC untuk tracing dan logging.
4. Interface Backward Compatibility: Jangan hapus field proto tanpa strategi fallback/versioning.

Kesimpulan

Menerapkan gRPC dalam sistem pemesanan tiket memberikan boost performa, konsistensi data, dan skalabilitas. Ia sangat cocok di ekosistem microservices yang polyglot, menuntut latency rendah, dan trafik tinggi.

Mau mulai dari mana? Coba replikasi skenario di atas, lakukan benchmark terhadap REST/HTTP, dan nikmati arsitektur yang lebih reliable untuk sistem-sistem distribusi tiket skala nasional.

Apakah Anda sudah pakai gRPC untuk service penting di perusahaan? Ceritakan pengalaman Anda di kolom komentar!

Referensi:

• gRPC Official Documentation
• Real World Race Condition Handling
• Protobuf vs JSON Benchmark

Sampai jumpa di tulisan berikutnya. Jangan lupa kasih 👏 dan share kalau bermanfaat!