Güvenli Ürünler: Aurora DSQL ile Ürün İadelerini Gerçek Zamanlı Engelle

İkinci el bir ürünün satın alınması sırasında karşınıza çıkan en büyük risklerden biri, o ürünün daha önce iade edilmiş olup olmadığını anlamakta yaşanan zorluktur. Bugünlerde ürün iadeleri genellikle bir web sayfası, PDF dokümanı veya e-posta yoluyla duyuruluyor. Bu durum, özellikle bebek ürünleri söz konusu olduğunda ölümcül sonuçlara yol açabiliyor. Yenilikçi bir proje olan SafeState, bu boşluğu doldurarak ürün iadelerini gerçek zamanlı olarak sisteme dahil ediyor ve ikinci el pazarlarında güvenliği artırmayı hedefliyor.

SafeState projesi, Amazon Aurora DSQL ve Vercel altyapısı üzerinde Next.js ön yüzüyle çalışıyor. Projenin temel amacı, ürün iadelerini sadece birer bildirimden ibaret olmaktan çıkarıp, anında sisteme dahil edilmesini sağlamak. Bu sayede, ikinci el bir ürün satılırken sistem otomatik olarak o ürünün iade listesinde olup olmadığını kontrol ediyor ve iade edilen ürünlerin satışını engelliyor.

Aurora DSQL'in Gücü: Gerçek Zamanlı Tutarlılık

SafeState'in en önemli vaadi, bir ürünün iade edildiği andan itibaren hiçbir pazar yerinde o ürünün "güvenli" olarak görülmemesini sağlamak. Bu, sadece bir iyileştirme değil, aynı zamanda güçlü bir tutarlılık gerektiren bir durum. Eğer sistemdeki veriler arasında herhangi bir gecikme varsa, o ürün hâlâ satılabilir olarak görünebilir ve bu durum ölümcül sonuçlara yol açabilir.

Aurora DSQL'in çok bölgeli, aktif-etkin yapısı ve güçlü tutarlılık özelliği, bu sorunu çözüyor. Proje geliştiricisi, ABD'nin doğu kıyısında iki bölgeyi (us-east-1 ve us-east-2) ve batı kıyısında bir bölgeyi (us-west-2) kullanarak gerçek bir peering kümesi kurmuş. Bu sayede, bir bölgeden yapılan bir iade işlemi, diğer bölgelerden anında okunabiliyor. Uygulamada yer alan bir sayfa, kullanıcıların bu işlemi kendileri deneyimlemesine olanak tanıyor.

Çakışmaları Engellemek için Tasarlanan Mekanizma

Aurora DSQL, PostgreSQL'in yinelemeli okuma özelliğini kullanarak optimistik eşzamanlılık sağlıyor. Bu sayede, aynı satır üzerinde yapılan yazma işlemleri arasındaki çakışmalar işlem tamamlanmadan yakalanabiliyor. Ancak, bu özellik tek başına yeterli değil. Güvenli bir sistem için, hem iade hem de satış işlemlerinin aynı satıra yazması gerekiyor.

Her ürün modeli için bir safety_guard satırı oluşturuluyor. Bu satır, ürünün durumunu ve bir epoch numarasını içeriyor. Aşağıdaki kod parçası, bu mekanizmanın nasıl çalıştığını gösteriyor:

await client.query("BEGIN");
await client.query("SELECT epoch FROM safety_guard WHERE model_id = $1 FOR UPDATE", [modelId]);

// Ürünün durumunu değerlendir
await client.query("INSERT INTO ownership_transfers (...) VALUES (...)");
await client.query("UPDATE product_instances SET current_owner_id = $1 WHERE id = $2", [buyer, id]);
await client.query("UPDATE safety_guard SET updated_at = now() WHERE model_id = $1", [modelId]);

await client.query("COMMIT");

Eğer iade işlemi önce tamamlanırsa, satış işlemi SQLSTATE 40001 (OC000) hatası alır. Bu durumda, sistem otomatik olarak işlemi yeniden deniyor ve ikinci denemede iadenin kaydedilmiş olduğunu algılayarak satışı engelliyor. Bu sayede, hiçbir şekilde iade edilen bir ürünün satılması mümkün olmuyor.

const RETRYABLE = new Set(["40001", "OC000", "OC001"]);
// Çakışma durumunda işlemi yeniden dene, gecikmeyle birlikte 3 denemeye kadar

Vercel Entegrasyonu ve Güvenlik

Vercel'deki rota yöneticileri, DSQL'e normal PostgreSQL protokolü üzerinden bağlanıyor. Ancak, bağlantı özel bir AWS IAM tokenıyla güvence altına alınıyor. Bu sayede, veritabanı şifresi gibi hassas bilgiler ortam değişkenlerinde saklanmıyor. Güvenlik, sadece bağlantı başına üretilen kısa ömürlü tokenlarla sağlanıyor.

Ayrıca, Vercel Cron görevi sayesinde her gün ABD Tüketici Ürünleri Güvenlik Komisyonu'nun (CPSC) API'sinden gerçek iadeler çekiliyor. Yapay zeka aracı Claude ise ikinci el ürün ilanlarını tarayarak hangi iadeyle eşleştiğini belirliyor. Belirsiz olan durumlar ise otomatik engelleme yerine inceleme kuyruğuna gönderiliyor.

Bu entegrasyon sırasında karşılaşılan bir diğer zorluk da AWS ortam değişkenlerinin Lambda tarafından rezerv edilmesiydi. AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY ve AWS_REGION gibi değişkenler doğrudan ortam değişkenleri olarak ayarlanamıyordu. Bu nedenle, DSQL kimlik bilgileri farklı isimlerle geçilerek doğrudan imzalayıcıya iletildi.

Deneyimlerden Çıkarılan Dersler

Eğer Aurora DSQL üzerinde çalışıyorsanız, eşzamanlılık sorununun ürününüzün merkezinde yer aldığından emin olun. Çakışmaları yakalamak için her iki işlemin de aynı satıra yazmasını sağlayın. Ayrıca, 40001 hatası için yeniden deneme mekanizmasını en başta geliştirin, çünkü bu hataya sıkça karşılaşacaksınız.

Ürün iadeleri artık sadece PDF dosyaları değil, aynı zamanda anında uygulanan kararlar olmalı. Aurora DSQL ve Vercel'in bir araya gelmesiyle, bu vizyon sadece bir hafta sonu projesiyle gerçeğe dönüşüyor.