Online Açık Artırma Platformu Nasıl Kurulur [2025 Teknik Rehberi]

Açık artırma platformları, teknik temellerin hatalı atılmasının yalnızca kötü bir kullanıcı deneyimine yol açmakla kalmadığı, doğrudan para kaybına, güven erozyonuna ve düzenlenmiş sektörlerde hukuki sorumluluğa neden olduğu nadir yazılım kategorilerinden birinde yer almaktadır. Bir saniye geç kaydedilen bir teklif. İki alıcının aynı lotu kazanmasına izin veren bir yarış koşulu. Bir cihazda diğerinden daha hızlı işleyen bir zamanlayıcı. Yetkilendirilen ancak hiç tahsil edilemeyen bir ödeme. Bunlar uç vakalar değildir. Bir açık artırma platformunu standart bir e-ticaret sitesi inşa eder gibi kurduğunuzda yaşananlar tam olarak bunlardır.

Sanat, antika, endüstriyel ekipman, canlı hayvan, araç ve ticari gayrimenkul sektörlerinde açık artırma ve pazar yeri platformları geliştirdik. Bu sektörlerin tamamında ortak olan nokta, teknolojinin gerçek anlamda zorlu olduğudur — bunun nedeni egzotik mühendislik gerektirmesi değil, çoğu web uygulamasının sahip olmadığı düzeyde kesinlik, tutarlılık ve gerçek zamanlı koordinasyon talep etmesidir.

Bu rehber tam teknik tabloyu kapsamaktadır: mimari kararlar, altyapı seçimleri, ihtiyaç duyduğunuz özellikler ve sorunu küçümseyen ekiplerin tekrar tekrar yaptığı hatalar. 2025 yılında açık artırma platformunu piyasaya sürmek için kurmanın mı, satın almanın mı yoksa ortaklık kurmanın mı doğru olduğunu değerlendiriyorsanız, bu rehber sunabileceğimiz en teknik ve dürüst analiz niteliğindedir.

---

Açık Artırma Formatlarının Türleri

Sonraki tüm teknik gereksinimleri şekillendiren ilk karar şudur: aslında ne tür bir açık artırma düzenliyorsunuz? Bu, platformu inşa ettikten sonra ele alınan bir ürün kararı değildir. Veri modelinizi, gerçek zamanlı gereksinimlerinizi, zamanlayıcı davranışınızı ve teklif motoru mantığınızı belirleyen temel bir kısıttır.

İngiliz Yükselen Açık Artırması

En tanıdık format. Bir lot başlangıç fiyatından açılır, teklif sahipleri giderek yükselen teklifler vererek rekabet eder ve kapanışta en yüksek teklif sahibi kazanır. Bu format Sotheby's, Christie's, eBay (ilk biçimiyle) ve çoğu canlı hayvan ile araç müzayedesinde kullanılmaktadır.

Teknik açıdan bu format, göründüğünden çok daha fazla talep içermektedir. Her teklifin gerçek zamanlı olarak mevcut en yüksek teklife karşı doğrulanması gerekir; bu da eski okumalara göz yumamayacağınız anlamına gelir. İki teklif sahibi birbirinden milisaniyeler farkla teklif gönderebilir — sisteminiz hangisinin önce geldiğini çözümlemeli, bunu atomik olarak uygulamalı ve yeni durumu bağlı tüm istemcilere anında yaymalıdır. Ölçekte (yüzlerce eş zamanlı lot, binlerce bağlı teklif sahibi) verim ve tutarlılık gereksinimleri ciddi mühendislik sorunlarına dönüşmektedir.

Hollanda İnen Açık Artırması

Fiyat yüksek başlar ve bir teklif sahibi kabul edene kadar tanımlı bir hızda düşer; kabul anında müzayede hemen kapanır. Çiçek pazarlarında, balık pazarlarında ve bazı ticari mülk tasfiye platformlarında kullanılır.

Buradaki teknik profil farklıdır. Eş zamanlı teklif rekabetini aynı şekilde ele almanız gerekmez; ancak her tik aralığında son derece doğru, sunucu-yetkili fiyat hesaplaması yapmanız gerekir. Zamanlayıcı dekoratif değildir — işlem fiyatını doğrudan belirler. İstemci tarafındaki birkaç yüz milisaniyelik kayma bile kabul edilen fiyat konusunda anlaşmazlıklara yol açabilir. Her kabul etkinliğinde imzalı zaman damgasıyla sunucu taraflı fiyat hesaplaması zorunludur.

Kapalı Zarf (Birinci Fiyat ve İkinci Fiyat)

Tüm teklif sahipleri maksimum tekliflerini diğerlerinin tekliflerini görmeden sunar. Birinci fiyat kapalı zarfta, en yüksek teklif sahibi verdiği teklif tutarını öder. İkinci fiyatta (Vickrey), ikinci en yüksek tutarı öder. Devlet ihalelerinde, ticari mülk ihracatlarında ve bazı uzman koleksiyoncu pazarlarında kullanılır.

Buradaki teknik gereksinimler yine farklıdır — daha az gerçek zamanlı karmaşıklık, ancak teklif gizliliği ve açıklama bütünlüğü konusunda çok daha fazla hassasiyet. Tekliflerin, açıklama penceresine kadar tüm taraflara (bazı düzenleyici bağlamlarda kendi operasyon ekibiniz dahil) erişilemez biçimde şifreli olarak saklanması gerekir. Kapalı zarf açık artırmalarının denetim izi sıklıkla incelendiğinden, kriptografik taahhüt planları veya en azından değiştirilemez olay günlüğü tutma zorunludur.

Taban Fiyatlı Açık Artırmalar

Bağımsız bir format değil, yukarıdakilerin herhangi birine uygulanan bir değiştiricidir. Bir lotun gizli bir minimum fiyatı (taban fiyat) vardır. Teklifler bu eşiğe ulaşmazsa satıcı satış yapmakla yükümlü değildir. Eşiğe ulaşırsa müzayedenin "piyasada" olduğu söylenir.

Bu durum lot modelinize durum ekler — her lotun taban fiyata ulaşılıp ulaşılmadığını takip etmesi gerekir ve bu durum, taban fiyat rakamının kendisini açıklamadan teklif sahiplerine iletilmelidir. Teklif motorunuzun her teklifte taban fiyat koşullarını değerlendirmesi ve buna göre bildirimleri tetiklemesi ("taban fiyata ulaşıldı") gerekmektedir.

Süreli Online Açık Artırma ve Canlı/Simulcast

Süreli online açık artırmalar eş zamansız olarak yürütülür — lotlar belirli bir süre boyunca (saatler, günler) açık kalır ve teklif sahipleri istedikleri zaman katılır. Canlı açık artırmalar eş zamanlıdır — bir insan müzayedecisi tempoyu kontrol eder ve salondaki ile çevrimiçi teklif sahipleri aynı anda rekabet eder. Simulcast her ikisini birleştirir: canlı bir müzayedeci salonu yönetirken çevrimiçi bir platform dış teklifleri gerçek zamanlı olarak aktarır.

Süreli açık artırmaların inşası önemli ölçüde daha kolaydır. Gerçek zamanlı gereksinimler mütevazıdır — güvenilir WebSocket güncellemelerine ihtiyaç duyarsınız, ancak tempo, birkaç yüz milisaniyedeki nihai tutarlılığın kabul edilebilir olduğu kadar yavaştır.

Simulcast, açık artırma yazılımındaki en zorlu sorunlardan biridir. İnsan konuşma hızında işleyen fiziksel bir salonu, ağ hızında işleyen çevrimiçi bir platformla birleştirirsiniz; teklif eşitliğini korurken müzayedecinin teklifleri kabul etme veya reddetme yeteneğini yönetmek ve çevrimiçi taraftaki gecikmenin teklif sahiplerini salon katılımcılarına kıyasla dezavantajlı konuma düşürmemesini sağlamak gerekir. Müşteriniz baştan simulcast düzenlemeyi planlıyorsa mimari buna göre tasarlanmalıdır — sonradan uyarlamak son derece zahmetlidir.

---

Açık Artırma Platformunun Temel Teknik Bileşenleri

Gerçek Zamanlı Teklif Motoru

Teklif motoru sistemin kalbidir. Teklif gönderimlerini alır, doğrular, uygular ve durum değişikliklerini yayar. Diğer tüm bileşenler onun doğruluğuna ve performansına bağlıdır.

WebSocket, Long-Polling ve Server-Sent Events Karşılaştırması

Gerçek zamanlı aktarım seçiminin önemli etkileri vardır:

• WebSockets (Socket.io veya yerel ws aracılığıyla) tam çift yönlü, kalıcı bağlantılar sağlar. Teklif sahipleri aynı bağlantı üzerinden teklif gönderir ve güncellemeler alır. Bu, platformun yüksek frekansta güncelleme göndermesi ve gerçek zamanlı teklif alması gereken canlı ve simulcast açık artırmalar için doğru seçimdir. Bağlantı yönetimi ek yükü (yeniden bağlantı mantığı, kalp atışları, oda/kanal yönetimi) önemsiz değildir ancak iyi anlaşılmıştır.
• Server-Sent Events (SSE) tek yönlüdür — sunucu istemciye güncellemeler iter, ancak gönderimler ayrı HTTP istekleri üzerinden gerçekleşir. Bu yöntem, etkileşim deseninin çoğunlukla "güncellemeleri izle, ara sıra teklif ver" şeklinde olduğu süreli açık artırmalar için iyi çalışır. SSE uygulanması daha kolaydır ve HTTP/2 yük dengeleyicilerinin arkasında daha iyi ölçeklenir; ancak gerçek anlamda etkileşimli deneyimler için tek bağlantı zarifliğini kaybeder.
• Long-polling, yeni açık artırma platformları için kaçınılması gereken eski bir kalıptır. Gereksiz sunucu yükü oluşturur, gecikme sürer ve durum yönetimini karmaşık hale getirir.

Açık artırma platformları için varsayılan önerimiz, lot başına odalar (lotlar) için Socket.io ile WebSocket kullanımı ve teklif olaylarının yapışkan oturumlar gerektirmeden birden fazla sunucu örneğine yayınlanabilmesi amacıyla Redis pub/sub katmanıyla birleştirilmesidir.

Teklif Motoru Mimarisi

Teklif motoru uygulama katmanında durumsuz olmalıdır. Tüm yetkili durum — mevcut en yüksek teklif, teklif artış tablosu, lot durumu, taban fiyat durumu — tüm örneklerin tutarlı biçimde okuyabildiği bir veri deposunda bulunur. Her teklif gönderimindeki akış:

1. Kimliği doğrulanmış istemciden teklif alın
2. Kimlik doğrulama ve aktif lot durumunu doğrulayın
3. Lot üzerinde atomik kilit edinin (aşağıdaki yarış koşulu işlemeye bakın)
4. Yetkili depodan mevcut en yüksek teklifi okuyun
5. Teklif tutarını minimum artışa karşı doğrulayın
6. Teklif sahibinin uygunluğunu doğrulayın (mevcut en yüksek teklif sahibi değil, askıya alınmamış)
7. Veritabanına yeni teklif kaydı yazın
8. Önbellekte lot durumunu güncelleyin
9. Kilidi serbest bırakın
10. Pub/sub kanalına teklif olayını yayınlayın
11. Tüm bağlı örnekler olayı alır ve bağlı istemcilerine güncelleme iletir

Doğru biçimde yürütülen bu akış, iki teklifin eş zamanlı uygulanamayacağını, durumun her zaman tutarlı olacağını ve bağlı her istemcinin pub/sub gidiş-geliş gecikmesi içinde aynı bilgiyi göreceğini garanti eder.

Teklif Doğrulama ve Yarış Koşulu İşleme

Açık artırma platformlarındaki yarış koşulları teorik değildir. Popüler bir lot kapanırken tek bir saniyede düzinelerce teklif almak yaygındır. Uygun eş zamanlılık kontrolleri olmaksızın, birden fazla teklif aynı "mevcut en yüksek teklifi" eş zamanlı okuyabilir, tümü doğrulamayı geçer ve tümü yazmaya çalışır — tutarsız durum, yanlış kazananlar ve anlaşmazlıklar üretir.

İyimser Kilitleme

Bir yaklaşım, veritabanı düzeyinde iyimser kilitlemedir. Her lot kaydı bir sürüm numarası taşır. Motorunuz mevcut durumu okuyup yeni bir teklif yazmaya çalıştığında, okuduğu sürümü koşul olarak dahil eder: UPDATE lots SET highest_bid = $1, version = version + 1 WHERE id = $2 AND version = $3. Okuma ile yazma arasında başka bir işlem yazma gerçekleştirdiyse sürüm koşulu başarısız olur, yazma reddedilir ve motor taze durumla yeniden dener. Bu yöntem orta düzey eş zamanlılık için iyi çalışır.

Redis Tabanlı Atomik İşlemler

Yüksek eş zamanlılık senaryoları için — kapanan bir lot üzerinde saniyede yüzlerce teklif — Lua scriptleri veya SET NX / INCR ilkellerini kullanan Redis atomik işlemlerini tercih ederiz. Redis komut yürütmesi için tek iş parçacıklıdır; bu, teklif durumunu okuyan, doğrulayan ve yazan bir Lua scriptinin herhangi bir iç içe geçme riski olmadan atomik olarak yürütüldüğü anlamına gelir. Kalıp:

-- Lua script (Redis tarafından atomik olarak yürütülür)
local current = redis.call('GET', KEYS[1])  -- current highest bid
if tonumber(ARGV[1]) > tonumber(current) then
  redis.call('SET', KEYS[1], ARGV[1])
  return 1  -- bid accepted
else
  return 0  -- bid rejected (outbid)
end

Veritabanı yazma işlemi ardından kalıcı bir kayıt olarak eş zamansız gerçekleşir; Redis ise canlı teklif durumu için yetkili gerçek kaynağı işlevi görür. Bu yaklaşım kilit çakışması olmaksızın binlerce eş zamanlı teklife ölçeklenir.

Sunucu Taraflı Yetkinin Önemi

Yeterince sık dile getirilemeyen bir kural: sunucu her zaman yetkilidir. İstemci taraflı teklif doğrulama yalnızca kullanıcı deneyimidir — açıkça geçersiz gönderileri engeller ancak son söz olarak hiçbir zaman güvenilmemelidir. İstemci taraflı geri sayım zamanlayıcısının lotun teklif sahibinin perspektifinden "kapandığı" zamanı belirlediği platformlar gördük; bu, sunucuda lot gerçekten kapandıktan sonra tekliflerin gönderilebilmesine izin veriyordu. Bu durum anlaşmazlıklara ve bazı düzenleyici bağlamlarda hukuki sorumluluğa yol açmaktadır.

Lot Yönetimi ve Katalog

Lot kataloğu platformun içerik omurgasıdır. Her lot en az şunlara ihtiyaç duyar:

• Lot kimliği: lot numarası, başlık, açıklama, provenance veya durum notları
• Medya: sıralı birden fazla görsel, isteğe bağlı video, isteğe bağlı belge ekleri (sertifikalar, değerleme raporları, ekspertiz raporları)
• Fiyatlandırma parametreleri: başlangıç teklifi, taban fiyatı (geçerliyse), teklif artış tablosu, hemen satın al fiyatı (geçerliyse)
• Zamanlama: lot açılış zamanı, lot kapanış zamanı, otomatik uzatma mantığı
• Durum makinesi: taslak, planlandı, açık, kapanıyor, satıldı, satılmadı, geri çekildi
• Satış bağlamı: bu lot hangi müzayede satışına ait, o satış içindeki sırası nedir

Otomatik Uzatma (Yumuşak Kapanış)

Teklif sahibinin katılımını ve platform gelirini önemli ölçüde artıran bir özellik yumuşak kapanıştır ("açık artırma devam ediyor" modu olarak da bilinir). Bir lotun kapanış zamanından önce tanımlı bir pencere içinde (genellikle son 2–5 dakika) teklif verildiğinde, kapanış zamanı sabit bir süre (genellikle 2–3 dakika) kadar otomatik olarak uzar. Bu durum, müzayedecinin eller havadayken lotu kapatmayacağı canlı salon dinamiklerini taklit eder.

Mantık basit görünse de ince uç vakalar içerir: izin verilen maksimum uzatma sayısı nedir? Satışın planlanan bitiş zamanı geldiğinde bir lot otomatik uzatma modundaysa ne olur? Bunlar lot modelinizde tanımlanmalı ve tutarlı biçimde uygulanmalıdır.

Alıcı/Satıcı Kimliği ve KYC

Açık artırmalar güvene bağlı işlemlerdir. Kimliğin görece düşük riskli olduğu standart e-ticaret ödemelerinin aksine, bir açık artırma platformunun şunları bilmesi gerekir:

• Teklif sahipleri iddia ettikleri kişilerdir
• Teklif sahiplerinin kazandıkları teklifleri karşılayacak mali kapasitesi vardır
• Satıcıların sattıkları şeyin meşru mülkiyeti vardır
• Her iki taraf da yaptırım listesinde yer almamakta veya AML kırmızı bayraklarına tabi değildir

KYC gereksinimleri sektöre göre farklılık gösterir. Belirli eşiklerin üzerinde çalışan sanat piyasaları, Birleşik Krallık ve AB'de Kara Para Aklamayla Mücadele Direktifi kapsamındadır. Araç müzayedelerinin tapu doğrulama gereksinimleri vardır. Endüstriyel ekipman müzayedeleri ihracat kontrol düzenlemeleriyle ilgilenmektedir. Platformunuzun KYC katmanı yalnızca bir mühendis tarafından değil, bir uyumluluk uzmanıyla birlikte tanımlanmalıdır.

Teknik uygulama açısından KYC, genellikle belge yakalama, canlılık kontrolleri ve izleme listesi taraması gibi işlemleri gerçekleştiren çeşitli üçüncü taraf sağlayıcılar aracılığıyla yürütülür — Onfido, Jumio, Veriff veya Stripe Identity. Platformunuz SDK'larını kayıt akışına entegre eder, kullanıcı kaydında bir KYC durum bayrağı depolar ve teklif erişimini bu duruma göre kısıtlar.

Zamanlayıcı Yönetimi

Zamanlayıcı, herhangi bir açık artırma platformunun en tartışmalı bileşenlerinden biridir ve en sık hatalı uygulananıdır. Kural mutlaktır: lotların ne zaman açılıp kapanacağını sunucu belirler. İstemci bu bilgiyi görüntüler.

Sunucu Taraflı Lot Kapanışı

Lot kapanışı, son teklifin zaman damgası veya istemci taraflı bir zamanlayıcının sıfıra ulaşması tarafından değil, sunucu taraflı bir zamanlanmış görev tarafından tetiklenmelidir. Kapanış penceresine giren lotları sorgulayan, durumlarını geçiren, kazananı belirleyen ve uzlaşma olaylarını gönderen arka plan işçisi (özel bir süreçte veya zamanlanmış bir bulut fonksiyonunda çalışan) kullanırız. Bu işçi idempotent olmalıdır — çökme ve yeniden başlatma nedeniyle iki kez çalışırsa bir lotu iki kez kapatmamalı veya yinelenen uzlaşma kayıtları oluşturmamalıdır.

Saat Senkronizasyonu

Görüntüleme amacıyla istemcilerin doğru geri sayım gösterebilmek için mevcut sunucu saatini bilmesi gerekir. Mevcut UTC zaman damgasını döndüren bir /api/time uç noktası sunuyoruz ve her WebSocket teklif etkinliğine imzalı bir sunucu zaman damgası ekliyoruz. İstemciler bağlantı kurulduğunda yerel saat ile sunucu saati arasındaki farkı hesaplayabilir ve tüm geri sayım hesaplamalarına bu ofseti uygulayabilir. Bu durum, sunucu lotu çoktan kapatmışken bir teklif sahibinin geri sayımının "2 saniye" gösterdiği kozmetik kaymayı önler; bu durum işlevsel etkisi olmasa bile güven sorunlarına ve destek taleplerine yol açmaktadır.

Bildirim Sistemi

Açık artırma platformları son derece büyük hacimde zamana duyarlı bildirim üretir: daha yüksek teklif uyarıları, lot açılış hatırlatıcıları, lot kapanış uyarıları, kazanan bildirimleri, ödeme talepleri ve satıcı uzlaşma teyitleri. Bildirim sistemi hem tasarım hem de altyapı açısından sıklıkla küçümsenmektedir.

Bildirim Kanalları

Çoğu açık artırma platformunun en az şunlara ihtiyacı vardır:

• Uygulama içi gerçek zamanlı bildirimler (bağlı istemcilere WebSocket push)
• E-posta bildirimleri (şu an platformda olmayan kullanıcılar için)
• SMS bildirimleri (yüksek değerli veya zamana kritik olaylar için — daha yüksek teklif uyarıları, lot kapanışı)
• Push bildirimleri (mobil istemciler için)

Hacim ve Kısıtlama

Bir lot kapandığında, daha yüksek teklif nedeniyle kazanamayan her teklif sahibi aynı anda "kazanamadınız" bildirimi alır. 200 teklif sahibi olan popüler bir lot için bu, tek bir anda 199 e-posta, 199 SMS mesajı (etkinleştirilmişse) ve 199 push bildirimi demektir. Bunu aynı 5 dakikalık pencerede kapanan 50 lotla çarpın ve dakikalar içinde 9.950 mesaj göndermeniz gerekir. E-posta sağlayıcılarının hız sınırları vardır. SMS ağ geçitlerinin verim kapasiteleri vardır. Push bildirim hizmetlerinin kendi kuyruk davranışları vardır.

Bildirim sistemi, her kanal için ayrı işçilerle, üstel geri çekilmeli yeniden deneme mantığıyla ve kuyruk derinliği izlemeyle kuyruk destekli olarak tasarlanmalıdır. Genellikle iş kuyruğu için BullMQ (Redis destekli) kullanırız; her bildirim kanalı için ayrı kuyruklar ve kazanan bildirimlerinin toplu daha yüksek teklif uyarılarından önce gönderilmesini sağlayan öncelik seviyeleri bulunmaktadır.

---

Önerilen Mimari

Monolit ve Mikro Servisler

2025'teki herhangi bir teknik mimari tartışmasında mikro servisler konusu kaçınılmazdır. Dürüst görüşümüz: ilk 18–24 ayındaki hemen hemen tüm açık artırma platformları için iyi yapılandırılmış modüler bir monolit doğru seçimdir.

Nedeni şudur. Mikro servisler gerçek operasyonel karmaşıklık getirir: dağıtık izleme, servis keşfi, servisler arası kimlik doğrulama, bileşenler arası ağ gecikmesi ve her servis için bağımsız dağıtım süreçleri. Bunlar büyük bir ekibiniz, yüksek trafiğiniz ve iyi anlaşılmış servis sınırlarınız olduğunda ödenmeye değer maliyetlerdir. Dört ila on mühendislik ekibiyle oluşturulan birinci versiyon açık artırma platformunda, bu maliyetler çözmeleri gereken sorunlardan neredeyse her zaman daha yüksektir.

Önerilen başlangıç mimarimiz, net dahili alan sınırlarına sahip modüler bir monolittir:

• bidding — teklif motoru, teklif doğrulama, yarış koşulu işleme
• lots — lot kataloğu, durum makinesi, zamanlayıcı yönetimi
• users — kimlik doğrulama, KYC durumu, alıcı/satıcı profilleri
• notifications — bildirim şablonları, kanal yönlendirmesi, gönderim işçileri
• payments — ödeme yetkilendirmesi, tahsilat, uzlaşma, faturalandırma
• admin — dahili araçlar, müzayede yönetimi, raporlama

Her modülün kendi modelleri, servisleri ve denetleyicileri vardır. Modüller arası iletişim, alan sınırları genelinde doğrudan veritabanı sorguları değil, iyi tanımlanmış dahili arayüzler aracılığıyla gerçekleşir. Bir servisi çıkarmanız gerektiğinde (teklif motoru en yaygın adaydır), sınırlar zaten mevcuttur.

Olay Güdümlü Kalıplar

Teklif alanı doğası gereği olay güdümlüdür. Teklif verildi → bid.submitted olayı. Teklif doğrulandı ve kabul edildi → bid.accepted olayı. Lot zamanlayıcısı sona erdi → lot.closing olayı. Kazanan belirlendi → lot.won olayı. Bu olaylar aşağı akış davranışları için tetikleyicilerdir: bildirim gönderimi, ödeme başlatma, satıcı pano güncellemeleri, denetim günlüğü girişleri.

Bunu monolit için dahili bir olay veriyolu ile uyguluyoruz (hız için senkron süreç içi, EventEmitter2 veya basit bir gözlemci kalıbı kullanarak) ve kalıcılık gerektiren her şey için harici bir olay veriyolu (Redis Streams veya hafif bir mesaj kuyruğu) kullanıyoruz — ödeme olayları, kazanan belirleme, uzlaşma teyitleri. Platform büyüdükçe ve servisler çıkarıldıkça, dahili veriyolu harici olana geçiş yapar.

Veritabanı Tasarım Hususları

Açık artırma veritabanı şeması, standart bir e-ticaret şemasından daha karmaşıktır. Temel tasarım kararları:

• Ayrı tablolar olarak lotlar ve teklifler yabancı anahtar ilişkisiyle — mevcut en yüksek teklifi, teklifler tablosuyla tutarlılığı sağlayan bir mekanizma olmaksızın lot kaydında sütun olarak hiçbir zaman saklamayın
• Her yerde yumuşak silme — açık artırma kayıtları finansal kayıttır; hiçbir şey kalıcı olarak silinmez
• Teklifleri satış veya zaman dilimine göre bölümlendirin — popüler bir platform onlarca milyon teklif kaydı biriktirebilir; bölümlendirme sorgu performansını öngörülebilir tutar
• Lot yazmaları üzerinde satır düzeyi kilitleme — PostgreSQL'in SELECT FOR UPDATE komutu, uygulama düzeyi Redis çözümü olmaksızın aynı lot kaydına eş zamanlı yazmaları önler

---

Teknoloji Yığını Önerileri

Açık artırma platformlarını üretimde oluşturma ve bakımını yapma deneyimimize dayanarak, mevcut önerilen yığınımız şöyledir:

Katman	Teknoloji	Gerekçe
Frontend	Next.js (React)	Katalog SEO'su için SSR, gerçek zamanlı teklif arayüzü için React
Stil	Tailwind CSS	Hızlı geliştirme, tutarlı tasarım birimleri
Gerçek zamanlı istemci	Socket.io client	Otomatik yeniden bağlantı, oda desteği
Backend	Node.js (TypeScript)	Yığın genelinde aynı dil, mükemmel WebSocket ekosistemi
REST/GraphQL API	Express veya Fastify	Kanıtlanmış, iyi anlaşılmış, kolay izlenebilir
Birincil veritabanı	PostgreSQL	ACID uyumluluğu, satır düzeyi kilitleme, güçlü topluluk
Önbellek / teklif durumu	Redis	Atomik Lua scriptleri, pub/sub, iş kuyruğu (BullMQ)
Gerçek zamanlı sunucu	Socket.io	Odalar, ad alanları, çok örnekli için Redis adaptörü
İş kuyrukları	BullMQ	Redis destekli, yeniden deneme mantığı, iş önceliklendirmesi
Medya depolama	AWS S3 / Cloudflare R2	Ölçeklenebilir, CDN'e hazır, önceden imzalanmış yükleme URL'leri
Görüntü işleme	Sharp / AWS Lambda	Küçük resim oluşturma, WebP dönüşümü
Arama	PostgreSQL tam metin veya Typesense	Lot kataloğunda tam metin arama
E-posta	SendGrid / Postmark	Teslimat takipli işlemsel e-posta
SMS	Twilio	SMS ve WhatsApp bildirimleri
Altyapı	AWS (ECS/EC2) veya Render	Yönetilen konteynerler, otomatik ölçekleme
CI/CD	GitHub Actions	Otomatik test ve dağıtım süreçleri
İzleme	Datadog veya Grafana Cloud	APM, hata takibi, kuyruk izleme

Neden Python değil? Python, açık artırma backend'leri için mükemmel bir seçimdir — Django'nun pazar yeri geliştirmede güçlü bir geçmişi vardır ve FastAPI eş zamansız iş yüklerini iyi işler. Node.js'i varsayılan olarak tercih ediyoruz çünkü frontend ile aynı dili paylaşarak ekip organizasyonunu ve bilgi paylaşımını kolaylaştırır. Ekibinizin güçlü olduğu alan Python ise o temel üzerine inşa etmekten memnuniyet duyarız.

Neden MongoDB değil? Teklif motorunun tutarlılık gereksinimleri — ilgili kayıtlar arası işlemler, satır düzeyi kilitleme, ACID güvenceleri — ilişkisel veritabanlarının belge depolarından gerçek anlamda daha iyi performans gösterdiği alanlardır. MongoDB işlem desteğini önemli ölçüde geliştirmiş olsa da PostgreSQL, bir açık artırma platformunun finansal veri modeli için daha doğal bir uyum olmaya devam etmektedir.

---

Temel Özellikler Kontrol Listesi

Üretime hazır bir açık artırma platformu, çoğu başlangıç kapsam belirleme çalışmasının hesaba kattığından daha büyük bir özellik seti gerektirir. Kullandığımız tam liste şöyledir:

Teklif Sahibi Deneyimi

• E-posta doğrulamalı teklif sahibi kaydı
• KYC/kimlik doğrulama akışı (entegre üçüncü taraf sağlayıcı)
• Teklif vermeden önce depozito veya kart saklama gereksinimi
• Filtreleme, sıralama ve arama özellikli lot kataloğu
• Tam medya galerisi ve lot detaylarına sahip bireysel lot sayfaları
• İzleme listesi / lotları sonra için kaydetme
• Gerçek zamanlı teklif güncellemeleriyle canlı teklif odası
• Vekil teklif (otomatik teklif): teklif sahibi bir maksimum belirler, sistem o tutara kadar onları temsilen teklif verir
• Taban fiyat durum göstergesi (karşılandı / henüz karşılanmadı)
• Hemen satın al seçeneği (uygulanabilir olduğu durumlarda)
• Daha yüksek teklif bildirimleri (uygulama içi, e-posta, SMS)
• Yumuşak kapanış uzatma göstergeleriyle lot kapanış geri sayımı
• Müzayede sonrası fatura oluşturma ve ödeme
• Sipariş geçmişi ve lot kazanma geçmişi
• Yaklaşan lotlar, aktif teklifler, kazanılan lotlar, ödeme durumu içeren teklif sahibi panosu

Satıcı / Komisyoncu Deneyimi

• Satıcı kaydı ve katılım süreci
• Lot gönderim formu (başlık, açıklama, görseller, taban fiyatı, başlangıç fiyatı)
• Lot onay iş akışı (yönetici incelemesi bekliyor)
• Lot performans verileri içeren satıcı panosu (görüntüleme, teklif, nihai fiyat)
• Satış sonrası uzlaşma bildirimleri
• Ödeme işleme ve geçmişi

Müzayede Evi / Yönetici Paneli

• Satış yönetimi (müzayede satışları oluşturma, planlama, kapatma)
• Lot yönetimi (onaylama, düzenleme, geri çekme, yeniden listeleme)
• Teklif sahibi yönetimi (onaylama, askıya alma, KYC durumunu inceleme)
• Canlı satış kontrol paneli (simulcast için: çevrimiçi teklifleri kabul/reddetme, lot sırasını kontrol etme)
• Lot başına teklif geçmişi ve denetim günlüğü
• Taban fiyatı yönetimi
• Uzlaşma yönetimi (lotları ödenmiş olarak işaretleme, ödemeleri başlatma)
• Raporlama (satış toplamları, alıcı primleri, satıcı net gelirleri, satılmama oranı)
• Finansal mutabakat dışa aktarma (muhasebe için CSV)

Platform / Altyapı

• Çoklu satış desteği (birden fazla eş zamanlı müzayede etkinliği yürütme)
• Beyaz etiket tema desteği
• Üçüncü taraf entegrasyonlar için API
• Mobil uyumlu web (veya yerel mobil uygulamalar)
• CDN üzerinden sunulan medya
• Gerçek zamanlı izleme ve uyarı

---

Ödeme ve Uzlaşma Mimarisi

Açık artırma ödemeleri, standart e-ticaret ödemelerinden temelden farklıdır ve bunlara aynı şekilde davranmak, gördüğümüz en yaygın hatalardan biridir.

Yetkilendirme-Bloke-Tahsilat Kalıbı

Standart e-ticarette ödeme ödeme sırasında tahsil edilir. Çoğu açık artırma formatında, teklif verme sırasında nihai fiyatı bilemezsiniz — ve bilseniz bile (lotun kapanışında vekil teklif durumunda), uzlaşma onaylanana kadar ödemeyi tahsil etmek istemeyebilirsiniz.

Çoğu açık artırma platformu için doğru kalıp şöyledir:

1. Ön yetkilendirme blokesi kayıt sırasında veya bir lota teklif vermeden önce — ödeme yöntemini doğrulamak ve finansal ciddiyeti göstermek için depozito tutarı için kart yetkilendirmesi (genellikle lot kategorisine bağlı olarak 250–2.000 £)
2. Kazanan belirleme — bir lot kapandığında sistem kazanan teklif sahibini ve nihai fiyatı belirler
3. Fatura oluşturma — çekiç fiyatı artı alıcı primi artı geçerli vergiler dahil olmak üzere fatura oluşturulur
4. Ödeme tahsilatı — kazanan teklif sahibinden kayıt depozitosundan ayrı olarak tam fatura tutarı istenir (veya otomatik olarak tahsil edilir)

Kayıt depozitosu yetkilendirmesi, kazanamayan teklif sahipleri için müzayede kapandıktan sonra genellikle serbest bırakılır. Kazanan teklif sahipleri için depozito, fatura toplamına mahsup edilebilir.

Müzayede Sonrası Uzlaşma

Çoğu müzayede evi müşterisi için uzlaşma döngüsü şöyledir:

1. Kazanan teklif sahibi faturayı öder (genellikle müzayede kapanışından 24–72 saat içinde)
2. Platform veya müzayede evi temizlenmiş fonların alındığını teyit eder
3. Alıcı lotu teslim alır veya teslimat düzenler
4. Satıcı ödemesi başlatılır (genellikle müzayede kapanışından 14–21 gün sonra, komisyon ve listeleme ücretleri düşülerek)

Her adım uzlaşma durum makinenizde takip edilmelidir. Ödenmemiş faturalar için otomatik hatırlatıcılar ve tanımlı bir süreden sonra yönetici ekibine yükseltme gereklidir. Satıcı ödemeleri, platformun fonları aktarım sırasında elinde tuttuğu pazar yeri tarzı platformlar için en yaygın seçenek olan Stripe Connect ile seçtiğiniz ödeme mekanizmasıyla entegre edilmelidir.

Ödeme Sağlayıcı Önerileri

Sağlayıcı	En Uygun Olduğu Durum	Notlar
Stripe	Birleşik Krallık, AB, ABD, çoğu pazar	En iyi API, pazar yeri ödemeleri için Stripe Connect
PayPal	PayPal güveninin yüksek olduğu pazarlar	Tamamlayıcı seçenek olarak faydalı
Braintree	Çok para birimi, yüksek hacim	PayPal'a ait, güçlü dolandırıcılık araçları
GoCardless	Birleşik Krallık/AB banka borcu	Büyük fatura uzlaşması için uygun
Checkout.com	Yüksek hacim, kurumsal	Ölçekte rekabetçi oranlar
Stripe + bölgesel	Küresel platformlar	Birincil olarak Stripe, yedek olarak bölgesel sağlayıcı

BAE veya KSA'da faaliyet gösteren platformlar için, yerel kart kapsamı amacıyla genellikle Stripe'ın yanı sıra PayTabs veya HyperPay uygularız.

---

KYC ve Dolandırıcılık Önleme

Açık artırmalar, basit bir nedenle standart e-ticarete kıyasla orantısız ölçüde fazla ödeme dolandırıcılığı ve kimlik dolandırıcılığı çekmektedir: teklif vermenin zaman baskısı dikkatli inceleme için daha az fırsat yaratır ve açık artırma platformları tarihsel olarak banka işlemlerinden daha az sürtünmeye sahiptir. Dolandırıcılar her ikisinden de yararlanır.

Açık Artırmaların Dolandırıcılık Çekmesinin Nedenleri

Karşılaştığımız yaygın dolandırıcılık kalıpları:

• Sahte teklif: satıcı (veya ortağı) çekiç fiyatını şişirmek için yapay teklifler verir. IP adresi analizi, cihaz parmak izi, teklif kalıbı analizi ve alıcı ile satıcı hesapları arasındaki ilişki haritalama yoluyla teknik olarak tespit edilebilir.
• Ödeme dolandırıcılığı: kazanan teklif sahibi depozito için çalıntı kart bilgilerini kullanarak ödeme yapmaksızın teklif verir. Dolandırıcılık, müzayededen günler sonra tahsilat sırasında keşfedilir.
• Kimlik dolandırıcılığı: teklif sahibi sınırlarını veya askıya almayı aşmak için yanlış kimlikler altında birden fazla hesap oluşturma.
• Satıcı dolandırıcılığı: sahip olmadıkları veya açıklamayla eşleşmeyen kalemleri listeleyen satıcılar, alıcı fonlarını toplayıp yerine getirmeden kaybolur.

Kimlik Doğrulama Yaklaşımları

Katman 1 — Yalnızca e-posta doğrulama: Yalnızca düşük değerli, düşük riskli lotlar için uygundur. Anlamlı bir dolandırıcılık önleme sağlamaz.

Katman 2 — Adres doğrulamalı kayıtlı kart: Eşleşen fatura adresiyle geçerli bir ödeme kartı gerektirir. Temel dolandırıcılık sürtünmesi sağlar. Orta seviye tüketici platformları için uygundur.

Katman 3 — Devlet tarafından verilen kimlik doğrulama: Pasaport veya sürücü belgesini doğrulamak ve bunu bir özçekimle eşleştirmek için KYC sağlayıcısıyla entegrasyon (Onfido, Jumio, Veriff). Bu, 1.000–2.000 £ üzerindeki lotları ele alan veya düzenlenen sektörlerde faaliyet gösteren platformlar için minimum standarttır.

Katman 4 — AML taramalı tam KYC: Siyasi nüfuz sahibi kişiler (PEP) ve yaptırım veritabanlarına karşı izleme listesi taramasıyla belge doğrulama. Birleşik Krallık'ın Kara Para Aklamayla Mücadele Yönetmelikleri kapsamındaki sanat piyasası operatörleri ve kurumsal veya yüksek net değerli alıcı tabanına sahip platformlar için gereklidir.

Depozito Gereksinimleri

Teklif vermeden önce ön yetkilendirme blokesi zorunlu tutmak, mevcut en yüksek değerli dolandırıcılık önleme mekanizmalarından biridir — dolandırıcılığı imkansız kıldığı için değil, bunu deneme maliyetini önemli ölçüde artırdığı için. Herhangi bir lota teklif vermeden önce depozito koymak için geçerli, doğrulanabilir bir kart gereksinimi, dolandırıcıların önünde anlamlı bir engel oluşturur.

Depozito eşikleri lot değer kategorisine göre kademelendirmelidir. Aynı satışta 50 £ ile 50.000 £ arasında lotlar düzenleyen bir platform, tüm teklif sahiplerinden aynı depozitoyu talep etmemelidir — bu hem düşük uçta erişimi aşırı kısıtlar hem de yüksek uçta yetersiz koruma sağlar.

---

Sık Yapılan Hatalar

Yarış Koşullarını Ele Almamak

Teknik açıdan en zararlı hata. Ekipler mutlu yolu inşa eder — bir teklif, bir teklif sahibi, testte çalışır — ve ardından canlıya geçer. Gerçek yük altında, eş zamanlı tekliflerle, veritabanının aynı lot üzerinde en yüksek teklif olduğunu iddia eden iki kayıt içerdiğini keşfederler. Müzayede canlıyken ve teklif sahipleri izlerken bunu üretimde düzeltme çabası tam olarak duyulduğu kadar ağırdır.

Düzeltme karmaşık değildir. Teklif motorunu inşa etmeye başlamadan önce bunu düşünmeyi gerektirir; ilk canlı satış bir veri bütünlüğü olayı ürettikten sonra değil.

İstemci Taraflı Zamanlayıcılara Güvenmek

Bunu hayal edilebilecek her biçimde gördük. Gönder düğmesinin ne zaman devre dışı kalacağını belirleyen JavaScript geri sayım zamanlayıcıları. Cihaz uyku moduna girdiği için sapan mobil uygulama zamanlayıcıları. Sekme arka plana geçtiğinde duran tarayıcı sekme zamanlayıcıları. Her durumda platform, yetkili gerçek kaynağı olmayan bir zamanlayıcıya göre tekliflere izin verir (veya reddeder).

Sunucu lotları kapatır. Sunucu, gönderim sırasındaki lot durumuna göre teklifleri kabul veya reddeder. İstemci zamanlayıcısı bir görüntüleme kolaylığıdır. Bunlar tamamen ayrı endişeler olarak ele alınmalıdır.

Bildirim Yükünü Küçümsemek

Bir satışta 500 kayıtlı teklif sahibi ve 100 lota sahip bir platform, canlı satışın iki saatinde yaklaşık 50.000 bildirim gönderir — daha yüksek teklif uyarıları, lot kapanış uyarıları, kazanan bildirimleri, ödeme talepleri. Tüm bunları tek bir senkron e-posta fonksiyonu üzerinden yönlendiren ekipler bunu en kötü anda keşfeder.

Bildirimler en başından eş zamansız, kuyruk destekli bir sistem olarak tasarlanmalıdır. Sonradan yeniden yapılandırma, canlı üretim sistemi sırasında bildirim gönderimini yeniden yazmayı gerektirir ve son derece zahmetlidir.

Tek Açık Artırma Formatı için İnşa Edip Sonradan Uyarlamak

Bir müşteri süreli online açık artırma ihtiyacıyla gelir. Ekip tam olarak bunu — tek fiyat görüntüleme, tek lot zaman çizelgesi, canlı teklif sahibi sayısı yok, veri modeline yerleşik simulcast desteği yok gibi varsayımlarla süreli bir açık artırma platformu — inşa eder. Altı ay sonra müşteri canlı simulcast özelliği eklemek ister. Bunu farklı varsayımlar etrafında tasarlanmış bir sisteme sonradan yerleştirme çalışması, düzenli olarak baştan doğru inşa etmekten daha pahalıya mal olmaktadır.

Müşterinin hangi açık artırma formatlarını çalıştırmayı planladığını anlamak — şimdi ve 18 ay içinde — mimari için bir ön koşuldur, sonradan düşünülmesi gereken bir şey değildir.

Vekil Teklif Maksimumlarını Görünür Biçimde Depolamak

Vekil teklif (otomatik teklif), teklif sahibinin maksimum tutarının saklanmasını gerektirir. Bu tutar dinlenmede şifrelenmiş olmalı ve müzayede evi personeli dahil hiçbir tarafın erişimine açılmamalıdır. Yönetici panelinde vekil maksimumlarının görünür olduğu, müzayede evi operatörüne müzayede kapanmadan önce her teklif sahibinin tavanını görme imkânı tanıyan platformları inceledik. Yargı yetkisine ve platform kurallarına bağlı olarak bu, ciddi bir güven ihlali ve potansiyel olarak hukuki bir sorumluluktur. Vekil maksimumlar şifreli olarak saklanmalı, yalnızca teklif motorunun teklif yerleştirme anında çözeceği şekilde tutulmalı ve hiçbir yönetim arayüzünde gün yüzüne çıkarılmamalıdır.

---

Cyberbeak'te Açık Artırma Platformlarını Nasıl İnşa Ediyoruz

Açık artırma ve pazar yeri platformlarını sıfırdan yeterince inşa ettik ve tekrarlanabilir bir sürecimiz var — ancak hiçbir iki müşterinin gereksinimleri özdeş olmadı ve bunu görmezden gelmiyoruz.

Sürecimiz

Keşif ve Mimari (1–3. haftalar): Açık artırma formatlarını, alıcı ve satıcı yolculuklarını, uyumluluk gereksinimlerini ve entegrasyon ortamını tanımlamak için yapılandırılmış atölyeler yürütüyoruz. Bir satır kod yazılmadan önce teknik mimari belgesi, veri modeli taslağı ve özellik spesifikasyonu üretiyoruz. Bu bürokratik bir adım değil — yukarıda açıklanan pahalı hataları önleyen aşamadır.

Temel İnşa (4–10. haftalar): Temel altyapı, kimlik doğrulama, KYC entegrasyonu, lot kataloğu, teklif motoru ve gerçek zamanlı WebSocket katmanı. Teklif motorunu önce inşa ediyor ve üzerine arayüzü inşa etmeden önce stres testlerine tabi tutuyoruz; çünkü arayüz kolaylıkla değiştirilebilir, teklif motoru ise değiştirilemez.

Özellik İnşa (11–16. haftalar): Alıcı ve satıcı panoları, bildirim sistemi, ödeme entegrasyonu, uzlaşma iş akışları, yönetici paneli, raporlama.

Entegrasyon ve Test (15–18. haftalar): Üçüncü taraf entegrasyon tamamlama, teklif motoru üzerinde yük testi (başlatmadan önce tahmini tepe eş zamanlılığın 10 katını hedefliyoruz), güvenlik incelemesi ve erişilebilirlik denetimi.

Pilot ve Lansman (18–20. haftalar): Halka açık lansmantan önce sınırlı teklif sahibi grubuyla denetimli bir pilot satış. Bu, hiçbir miktarda testin yüzeye çıkaramayacağı operasyonel sorunları yakalar — destek sorularını, gerçek teklif sahibi davranışındaki uç vakaları, müzayedecinin iş akışının yönetici paneli varsayımlarıyla örtüşmediği anları.

Tipik Zaman Çizelgesi

• Süreli online açık artırma, tek format, standart özellik seti: 12–16 hafta
• Canlı/simulcast yetenekli platform: 16–22 hafta
• Birden fazla açık artırma formatı, özel entegrasyonlar, mobil uygulamalar içeren kurumsal platform: 24–36 hafta

Yatırım Aralığı

Açık artırma platformu geliştirme, standart e-ticaretten daha yüksek bir yatırım diliminde yer almaktadır; çünkü teknik karmaşıklık gerçek anlamda daha yüksektir ve hata yapmanın maliyeti de öyledir. Tipik proje aralıklarımız:

• Süreli online açık artırma — standart kapsam: 80.000–130.000 £
• Canlı / simulcast yetenekli platform: 130.000–180.000 £
• Kurumsal çok formatlı platform: 180.000–250.000 £+

Bu rakamlar, kıdemli mühendisler ve eksiksiz bir teslimat süreciyle Birleşik Krallık merkezli bir teslimat ekibini yansıtmaktadır. Yalnızca yurt dışı teslimatı maliyeti düşürebilir; ancak bu problemin hassasiyet derecesinin bu kadar önemli olduğu alanda genellikle koordinasyon yükünü ve riski artırır.

---

Sıkça Sorulan Sorular

Süreli online ile başlayıp sonra simulcast özelliği ekleyebilir miyiz?

Evet, ancak bunu doğru yapmanın maliyeti büyük ölçüde ilk platformun nasıl mimarize edildiğine bağlıdır. Veri modeli, gerçek zamanlı katman ve yönetici paneli özellik uygulanmamış olsa bile gelecekteki simulcast göz önünde bulundurularak inşa edildiyse, ekleme bir uzantı niteliğindedir ve genellikle 8–14 haftalık çalışmadır. İlk inşa, canlı işlevselliğe herhangi bir düşünce verilmeden saf süreli müzayedeler için optimize edilmişse, çalışma kısmi bir yeniden inşaya daha yakındır. İlk mimariye özellik daha sonra gelse bile simulcast hazırlığını eklemenizi her zaman öneririz.

Platform kaç eş zamanlı teklif sahibini karşılayabilir?

WebSocket katmanında yatay ölçeklemeyle (yük dengeleyicinin arkasında dağıtılan Redis adaptörlü Socket.io) ve Redis'in teklif durumunu atomik olarak işlemesiyle, iyi inşa edilmiş bir platform yüzlerce eş zamanlı lot genelinde binlerce eş zamanlı bağlı teklif sahibini rahatça karşılayabilir. Sınırlayıcı faktör neredeyse her zaman teklif motorunun kendisi değil, bildirim gönderim katmanıdır. Gerçekten aşırı eş zamanlılık gereksinimleri olan platformlar için — on binlerce eş zamanlı teklif sahibi — mimari ayrıca kapsamlandırdığımız daha özel altyapı gerektirir.

Açık artırma platformu projelerinin bir parçası olarak mobil uygulama inşa ediyor musunuz?

Mobil tarayıcılarda iyi çalışan duyarlı web uygulamaları standart olarak inşa ediyoruz. Özel iOS ve Android uygulamaları, proje kapsamına ek olarak sunulmaktadır ve genellikle toplam yatırıma 8–14 hafta ve 30.000–60.000 £ ekler. Çoğu açık artırma platformu için iyi inşa edilmiş bir mobil web deneyimi, kullanım durumlarının %85–90'ını karşılar. Yerel uygulamalar, push bildirimleri, lot incelemeleri için kamera erişimi veya derin çevrimdışı destek gerektiğinde değer katar.

Uyumluluk açısından — açık artırma platformlarına özgü düzenleyici gereksinimler var mı?

Evet, ve sektöre ve coğrafyaya göre farklılık gösterir. Birleşik Krallık'taki sanat piyasası operatörleri, AML yükümlülükleri, KYC gereksinimleri ve işlem raporlama görevleri öngören 2017 Kara Para Aklaması, Terörün Finansmanı ve Fon Transferleri Yönetmelikleri (değiştirilen biçimiyle) kapsamında düzenlenmektedir. Araç müzayedelerinin tapu ve tescil hususları vardır. Gıda ve tarım müzayedeleri sektöre özgü lisanslama rejimleri kapsamında faaliyet gösterir. Ateşli silahların ve bazı emtiaların ihracat kontrol sonuçları vardır. Platform lansmanından önce uzman bir hukuk danışmanıyla uyumluluk incelemesi yapmanızı ve bu incelemenin ürettiği uyumluluk duruşunu desteklemek için teknik altyapıyı inşa etmenizi her zaman öneririz.

Platform diğer müzayede evleri için beyaz etiketlenebilir mi?

Evet. Platformları, isteğe bağlı mimari özellikler olarak çok kiracılı yapı ve beyaz etiketleme ile inşa ediyoruz. Beyaz etiket modeli — birden fazla müzayede evinin kendi markaları, katalogları ve teklif sahibi tabanlarıyla aynı temel platform üzerinde faaliyet gösterdiği — daha karmaşık bir başlangıç mimarisi gerektirir (veri katmanında kiracı izolasyonu, kiracı başına yapılandırma, alt alan adı veya özel alan adı yönlendirmesi); ancak birden fazla müzayede evi müşterisine hizmet vermek isteyen platform operatörleri için ticari açıdan çekici bir modeldir. Bu modeli başarıyla inşa ettik ve ilk inşa maliyetine yaklaşık %30–40 eklerken önemli ölçüde daha ölçeklenebilir bir ticari model sunar.

---

İnşa Etmeye Hazır mısınız?

Bir açık artırma platformu inşası değerlendiriyorsanız — ister online'a geçen köklü bir müzayede evi olun, ister uzman bir dikey sektöre giren bir girişim, isterse eski bir sistemi değiştirmek isteyen bir operatör — konuşmak isteriz.

Üstlendiğimiz projeler konusunda seçiciyiz; çünkü açık artırma platformları iyi inşa edilmek için derin bir işbirliği gerektirir. İlk görüşme her zaman bir teknik tartışmadır, satış görüşmesi değil. Zaman çizelgeleri veya maliyetler hakkında herhangi bir şey söylemeden önce açık artırma formatınızı, teklif sahibi tabanınızı, uyumluluk ortamınızı ve ticari modelinizi anlamak istiyoruz.

O konuşmayı başlatmak için Cyberbeak ekibiyle iletişime geçin.