İçeriğe atla
GeliştiriliyorBackendOlay tabanlı pazaryeri

TradeHub

İki taraflı onay protokolüne sahip takas pazaryeri

Rol
Tasarım ve backend
Dönem
2025 —
Durum
Geliştiriliyor
Bağlantılar
—

Rakamlarla

2
aşamalı onay protokolü
5+
mikroservis
0
tek taraflı iptal yolu

Genel bakış

Takas pazaryeri. Emanet (escrow) olmadan iki yabancı arasında güveni, iki taraflı onay protokolüyle kuruyor.

  • İki aşamalı el sıkışma: iki taraf da onaylamadan takas kapanmıyor; tek taraflı iptal saldırısı tasarım gereği imkânsız.
  • Outbox deseni sayesinde bir servis işlem ortasında çökse bile takas durumu kaybolmuyor.
  • Google OAuth2 ve rol bazlı erişim kontrolü 5+ servisi kapsıyor.

01

Problem

Takas işlemlerinde para olmadığı için klasik pazaryerlerindeki emanet (escrow) mekanizması kullanılamıyor. İki kullanıcı eşya değiştirirken taraflardan biri gönderimi, diğeri teslim almayı onaylamazsa sistemin işlem durumunu tutarlı biçimde belirlemesi gerekiyor.

02

Yaklaşım

Takası iki aşamalı bir el sıkışma protokolü olarak modelledim: önce iki taraf da teklifi kilitler, sonra iki taraf da teslimatı onaylar. Hiçbir aşama tek taraflı geri alınamıyor; durum makinesi geçersiz geçişleri reddediyor.

Durum geçişleri transactional outbox üzerinden Kafka'ya yayınlanıyor; bildirim, itibar ve envanter servisleri bu olayları tüketiyor. Servislerden biri çökse bile takas durumu veritabanında güvende.

Kimlik için Google OAuth2, yetki için rol bazlı erişim kontrolü; 5'ten fazla servis aynı güvenlik modelini paylaşıyor.

03

Mimari

  1. İstemci
    • Web uygulaması
    • Google OAuth2
  2. Çekirdek
    • Takas servisi (durum makinesi)
    • İlan servisi
    • Kullanıcı servisi
  3. Olaylar
    • Outbox
    • Kafka
  4. Tüketiciler
    • Bildirim
    • İtibar
    • Envanter
  5. Veri
    • PostgreSQL
    • Redis
↓ Veri akışı yukarıdan aşağıya

04

Kilit kararlar

  1. 01

    Saldırıyı tespit etmek yerine imkânsız kılmak

    Tek taraflı iptali sonradan yakalamak yerine protokol onu hiç izin verilen bir geçiş yapmıyor. Doğruluk kontrol listesinden değil, durum makinesinden geliyor.

  2. 02

    Her durum geçişi bir olay

    Takas servisi yalnızca kendi durumunu bilir; diğer servisler Kafka'dan gelen olaylarla tepki verir. Yeni bir servis eklemek mevcutları değiştirmiyor.

Sonuç

Çekirdek protokol ve servisler hazır; CI/CD boru hattı tamamlanınca yayına alınacak.

Ne öğrendim

“Güven gerektiren akışlarda önce geçerli durum geçişlerini tanımlayıp sonra arayüzü tasarlamak, hatalı senaryoları baştan eliyor.”

Benzer projeler

  • Backend
    Özel repo

    Taskify

    Beş mikroservis, 20ms altı gerçek zamanlı senkronizasyon

    Beş ayrık mikroservisten oluşan görev yönetimi; Redis ve Kafka ile kullanıcılar arasında 20ms altı gecikmeyle gerçek zamanlı durum senkronizasyonu.

    5
    mikroservis
    <20ms
    senkronizasyon gecikmesi
    • Java
    • Spring Boot
    • Redis
    • Kafka
    • PostgreSQL
    • Docker
    İncele
  • SaaS
    Canlı

    CestaLex

    Türk mahkemeleri için yapay zekâ destekli içtihat araştırma platformu

    Hukuk büroları için içtihat araştırma platformu. Yargıtay, Bölge Adliye Mahkemeleri ve Anayasa Mahkemesi kararlarında anlam tabanlı arama, akış yanıtlı yapay zekâ asistanı ve belge editörü sunuyor.

    3
    izolasyon katmanı
    3
    yüksek mahkeme külliyatı
    • Java 21
    • Spring Boot
    • PostgreSQL
    • Kafka
    • Redis
    • Qdrant
    İncele
    Siteye git ↗
  • SaaS
    Canlı

    CestaLaw

    Avrupa İnsan Hakları Mahkemesi içtihadı için araştırma platformu

    CestaLex'in kardeş ürünü; Avrupa İnsan Hakları Mahkemesi içtihadına odaklanıyor ve diğer Avrupa yargı alanlarına doğru genişliyor.

    1
    ortak platform temeli
    2
    farklı yargı alanı
    • Java
    • Spring Boot
    • React
    • Kafka
    • Redis
    • Docker
    İncele
    Siteye git ↗