Skip to content
In developmentBackendEvent-driven marketplace

TradeHub

Barter marketplace with a two-sided confirmation protocol

Role
Design & backend
Period
2025 —
Status
In development
Links
—

By the numbers

2
phase confirmation protocol
5+
microservices
0
single-sided cancellation paths

Overview

A barter marketplace. With no escrow, trust between two strangers is built through a two-sided confirmation protocol.

  • Two-phase handshake: a trade can't settle unless both sides confirm, making the single-sided cancellation attack impossible by design.
  • The outbox pattern keeps trade state safe even if a service dies mid-transaction.
  • Google OAuth2 and role-based access control span 5+ services.

01

Problem

Because no money changes hands in barter, the escrow mechanism of classic marketplaces does not apply. When two users exchange goods, the system must determine the transaction state consistently even if one side confirms shipping and the other never confirms receipt.

02

Approach

I modelled the trade as a two-phase handshake: both sides first lock the offer, then both confirm delivery. No phase can be undone unilaterally; the state machine rejects invalid transitions.

State transitions are published to Kafka through a transactional outbox; notification, reputation and inventory services consume them. Even if a service crashes, the trade state is safe in the database.

Google OAuth2 for identity, role-based access control for authorization; more than five services share the same security model.

03

Architecture

  1. Client
    • Web uygulaması
    • Google OAuth2
  2. Core
    • Takas servisi (durum makinesi)
    • İlan servisi
    • Kullanıcı servisi
  3. Events
    • Outbox
    • Kafka
  4. Consumers
    • Bildirim
    • İtibar
    • Envanter
  5. Data
    • PostgreSQL
    • Redis
↓ Data flows top to bottom

04

Key decisions

  1. 01

    Make the attack impossible instead of detecting it

    Rather than catching single-sided cancellation after the fact, the protocol simply never allows it as a transition. Correctness comes from the state machine, not from a checklist.

  2. 02

    Every state transition is an event

    The trade service knows only its own state; every other service reacts to Kafka events. Adding a new service changes nothing in the existing ones.

Outcome

The core protocol and services are complete; it ships once the CI/CD pipeline is finished.

What I learned

“In flows that require trust, defining the valid state transitions before designing the interface eliminates faulty scenarios from the start.”

Related projects

  • Backend
    Private repo

    Taskify

    Five microservices, sub-20ms real-time synchronization

    Task management across five decoupled microservices, with Redis and Kafka syncing state between active users at sub-20ms latency.

    5
    microservices
    <20ms
    sync latency
    • Java
    • Spring Boot
    • Redis
    • Kafka
    • PostgreSQL
    • Docker
    Open
  • SaaS
    Live

    CestaLex

    AI-assisted case-law research platform for the Turkish courts

    A case-law research platform for law firms, covering Yargıtay, the regional courts of appeal and the Constitutional Court, with semantic search, a streaming AI assistant and a document editor.

    3
    isolation layers
    3
    high-court corpora
    • Java 21
    • Spring Boot
    • PostgreSQL
    • Kafka
    • Redis
    • Qdrant
    Open
    Visit site ↗
  • SaaS
    Live

    CestaLaw

    Research platform for European Court of Human Rights case law

    Sister product to CestaLex, focused on European Court of Human Rights case law and expanding toward wider European jurisdictions.

    1
    shared platform foundation
    2
    distinct jurisdictions
    • Java
    • Spring Boot
    • React
    • Kafka
    • Redis
    • Docker
    Open
    Visit site ↗