Zomato'da Sipariş İptal Sorunu: SQS ve Sıralama Riski – webdedik gönderisi

Zomato'da Sipariş İptal Sorunu: SQS ve Sıralama Riski

Gece yarısı Zomato'dan pizza sipariş ettin, ödeme yaptın ama Paytm bakiye yetersiz gösterdi ve sipariş iptal oldu. Senin gözünden: sipariş ödeme iptal. Ama backend'de çok farklı bir hikaye dönüyor.

Zomato'nun sipariş servisi AWS SQS (Simple Queue Service) kullanıyor. SQS bir kuyruk gibi çalışıyor, ama standart SQS FIFO (First In First Out) garantisi vermiyor. Bunun yerine en iyi çabayı gösteriyor ve daha ucuz. Sorun burada başlıyor.

Senin sipariş olayı kuyruğa girdi. Ama önünde 5 tane başka olay var ve 5 farklı worker bunları işliyor. Standard SQS'te bu olaylar sırasız işlenebiliyor. Mesela iptal olayı ilk çıkıyor, Chef1 worker'ı bunu alıyor. Chef1 veritabanında iptal edilen siparişi arıyor ama bulamıyor çünkü oluşturma olayı henüz işlenmedi. Sonra Chef2 worker'ı oluşturma olayını işliyor ve siparişi veritabanına yazıyor. Sonuç: ödeme yapılmayan bir sipariş sisteme kaydediliyor.

Bu sorunu çözmek için birkaç yol var. Birincisi FIFO queue kullanmak ama daha pahalı. İkincisi, her siparişe bir ID vermek ve idempotency kontrol etmek, aynı olayı iki kez işlersen de sorun olmasın. Üçüncüsü, saga pattern kullanarak dağıtık işlemleri koordine etmek. Dördüncüsü, event sourcing ile tüm olayları kronolojik sırada tutmak.

Zomato gibi büyük sistemlerde bu tür race condition'lar finansal kayıplara neden olabiliyor. Bhanu Partap'ın detaylı sistem tasarımı yazısında bu problemi derinlemesine görebilirsin. Kısacası: dağıtık sistemlerde sıralama garantisi pahalı ama bazen gerekli.

konu hakkında tepkinizi verebilirsiniz