Representative engineering case study This case study presents a generalized engineering scenario based on the solution domain and capabilities represented in our portfolio. Client identities, confidential implementation details, and commercially sensitive information are intentionally omitted.

Web Platforms United States • Year 2021

Building a Real-Time Trading Marketplace Architecture

Designing a peer-to-peer asset exchange and counter-proposal system with bilateral trade verification and state machine synchronization.

Domain Web Platforms

Deployment Geography United States

Primary Discipline Web Applications

Delivery Status Representative Architecture

System Specs Ver. 2.0

Preferred Technology Stack

Application

Node.js · TypeScript

Frontend

Next.js · React · TypeScript

Data

PostgreSQL · OpenSearch

Infrastructure & Cloud

AWS

Real-Time & Messaging

WebSockets · Redis Pub/Sub

Commerce & Payments

Stripe Connect

These technologies represent a preferred architecture for this class of system and are not intended to identify the confidential historical implementation of any particular client project.

Architectural Capabilities

Marketplace transactions
Inventory locking
Real-time negotiation
Multi-party workflows

Engineering Consultation

Have similar scaling needs?

Review requirements with our senior engineering directors.

Schedule Call →

Topology Progress

01 Context → 02 Challenge → 03 Architecture → 04 Implementation → 05 Outcomes

01. Context & Objectives

Direct trade marketplaces allow participants to barter goods, negotiate terms, propose counter-offers, and confirm multi-item exchanges without cash intermediaries.

Architectural Mandate

Guarantee atomic transaction states across multiple traded items, eliminate item double-promising, and provide real-time offer status updates.

02. The Architectural Challenge

Scaling Constraints & Critical Bottlenecks

Managing multi-party counter-offers where items may be concurrently proposed in different trades requires strict concurrency locks to prevent double-commitment.

As trade proposals evolve through counter-offers, inventory states must dynamically update to reflect reservations without permanently locking user assets before agreement.

03. Engineering Approach & System Design

Decoupled Architecture & Execution Strategy

Modelled trade negotiation as a formal finite-state machine (Draft -> Proposed -> Under Review -> Counter-Offered -> Accepted/Rejected -> Completed) with transactional locking on inventory items.

System Data Flow Topology

Stages: •

STAGE 01

Marketplace UI

Processing →

STAGE 02

Trade State Machine Gateway

Awaiting Ingress →

STAGE 03

Concurrency Lock Manager

Awaiting Ingress →

STAGE 04

Relational Inventory Engine

Awaiting Ingress →

STAGE 05

Notification Dispatcher.

Awaiting Ingress

Deterministic isolation between ingestion ingress and persistence storage.

04. Implementation & Key Deliverables

What Urjasoft Built & Deployed

Delivered a deterministic peer-to-peer trading engine with formal state machine transitions, automated conflict resolution, and real-time negotiation feeds.

When a trade proposal is formally accepted, competing pending offers involving the same assets are automatically transitioned to void status with clear participant notices.

Implementation Details

Structured database transactions with optimistic locking on trade revisions, automated withdrawal of conflicting proposals upon trade acceptance, and asynchronous activity logs.