DEV Community: Ramanand Tomar

Building a Zero-Cloud P2P File Sharing Engine with React Native, TCP Sockets, and UDP Broadcasting

Ramanand Tomar — Mon, 12 Oct 2026 06:18:06 +0000

Standard mobile file sharing solutions frequently route local data through intermediary cloud storage infrastructure. Relaying gigabyte-scale payloads through centralized cloud buckets introduces substantial network latency, incurs redundant bandwidth expenditure, and presents clear data isolation risks. To overcome these constraints, I designed and developed ShareConnect, a high-throughput, serverless, peer-to-peer (P2P) file transfer application built with React Native, raw TCP socket streams, UDP subnet broadcasting, and MMKV. This document details the network handshake protocol, chunked streaming pipeline, backpressure management, and architecture required to achieve 30 to 50+ MB/s direct throughput across local network interfaces.

1. Direct Peer Discovery and Handshake Protocol

Establishing an offline transport between two client runtimes without an intermediary signaling server requires a deterministic three-phase lifecycle:

sequenceDiagram
    autonumber
    actor Receiver as Receiver Node
    actor Sender as Sender Node
    Note over Receiver: Phase 1: Subnet Beacon
    Receiver->>Receiver: Bind Socket to Local Hotspot / WLAN
    Receiver->>Sender: UDP Broadcast on 255.255.255.255:8888
    Note over Receiver,Sender: Phase 2: Visual Cryptographic Handshake
    Receiver->>Receiver: Render QR Payload (IP: 192.168.43.1, Port: 4000, Nonce)
    Sender->>Receiver: Capture QR Payload via Camera Sensor
    Sender->>Sender: Extract Transport Coordinates and Session Key
    Note over Receiver,Sender: Phase 3: Raw TCP Connection Initialization
    Sender->>Receiver: TCP SYN -> Connect to 192.168.43.1:4000
    Receiver-->>Sender: TCP SYN-ACK -> Establish Persistent Socket
    Sender->>Receiver: Emit Handshake Frame (`client_connected`)
    Receiver-->>Sender: Acknowledge Handshake Frame
    Note over Receiver,Sender: Full-Duplex Binary Stream Established

The Three Protocol Stages:

UDP Subnet Discovery (react-native-udp): The receiving device issues periodic datagram beacons across the local broadcast domain (255.255.255.255:8888) to advertise availability.
Visual QR Exchange: Eliminates manual IP configuration and local mDNS discovery latency by embedding endpoint coordinates, port configuration, and an ephemeral session nonce into an optically scannable matrix.
Persistent TCP Socket (react-native-tcp-socket): The sender connects directly to the receiver's socket server over the local IP interface, creating an uninterrupted, full-duplex transmission path.

2. Chunked Binary Streaming Engine

Reading large binary payloads into JavaScript heap memory triggers Out-of-Memory (OOM) termination in the Hermes and V8 runtimes. The transmission pipeline segments the input stream into 64 KB binary frames, streaming them sequentially while enforcing write backpressure at the destination node.

flowchart TD
    Init[Select Source File: 1.5 GB Binary] --> PreFlight[Extract File Stats: Total Chunks, Size, SHA-256 Checksum]
    PreFlight --> HeaderFrame[Transmit Metadata Acknowledgment Frame]
    subgraph Transmission Loop
        HeaderFrame --> Slice[Read 64 KB Block via react-native-fs]
        Slice --> SocketWrite[socket.write: Binary Chunk Frame]
        SocketWrite --> WaitAck{Wait for send_chunk_ack?}
        WaitAck -- ACK Received --> Incr[Advance Window: Index + 1]
        Incr --> BoundaryCheck{All Chunks Dispatched?}
        BoundaryCheck -- No --> Slice
    end
    subgraph Ingestion Loop
        SocketRead[Socket Event: data] --> FrameParse[Extract Chunk Index and Payload]
        FrameParse --> DiskWrite[Append to File Stream via MMKV / Storage Engine]
        DiskWrite --> EmitAck[socket.write: send_chunk_ack]
        EmitAck --> WaitAck
    end
    BoundaryCheck -- Yes --> Finalize[Compute Disk SHA-256 Digest]
    Finalize --> IntegrityVerify{Digest Valid?}
    IntegrityVerify -- Yes --> TargetFile[Mark Complete in Storage]
    IntegrityVerify -- No --> ErrorState[Flag Transmission Corruption]

3. Backpressure Flow Control: Mitigating Buffer Saturation

Over a 5 GHz local Wi-Fi interface, network throughput often surpasses flash memory sequential write speeds. Uncontrolled socket writes lead to rapid expansion of the underlying OS socket buffer, leading to high garbage collection overhead and dropped TCP connections. To prevent this, the client implements explicit frame-level acknowledgment flow control:

// Receiver: TCPUtils.ts
export const receiveFileAck = async (
  metadata: FileMetadata,
  socket: any,
  setReceivedFiles: any,
): Promise<void> => {
  const { setChunkStore } = useChunkStore.getState();

  // Initialize receiving chunk state machine
  setChunkStore({
    id: metadata.id,
    totalChunks: metadata.totalChunks,
    name: metadata.name,
    size: metadata.size,
    mimeType: metadata.mimeType,
    chunkArray: []
  });

  // Signal sender to begin transmitting chunk index 0
  socket.write(JSON.stringify({ event: 'send_chunk_ack', chunkNo: 0 }));
};

The sender waits for send_chunk_ack before slicing and dispatching the subsequent segment from the storage layer:


typescript
// Sender: TCPUtils.ts
export const handleChunkAck = async (
  ackPayload: { chunkNo: number },
  fileRecord: FileRecord,
  socket: any
): Promise<void> => {
  const nextChunk = ackPayload.chunkNo;
  if (nextChunk < fileRecord.totalChunks) {
    const chunkData = await RNFS.read(
      fileRecord.uri,
      CHUNK_SIZE,
      nextChunk * CHUNK_SIZE,
      'base64'
    );
    socket.write(JSON.stringify({ event: 'file_chunk', chunkNo: nextChunk, data: chunkData }

Building a Zero-Cloud P2P File Sharing Engine with React Native, TCP Sockets, and UDP Broadcasting

Ramanand Tomar — Mon, 12 Oct 2026 06:10:59 +0000

Architecting a High-Concurrency Railway Booking Platform with Node.js, Apache Kafka, and Redis Distributed Locks

Ramanand Tomar — Mon, 12 Oct 2026 06:01:22 +0000

By Ramanand Tomar — Software Engineer & Backend Systems Specialist

Handling massive bursts of concurrent requests during narrow reservation windows is one of the classic challenges in distributed system design. When thousands of transactions attempt to reserve the final remaining berth on a high-demand route simultaneously, standard relational locking mechanisms fail under contention.

In engineering the backend for IRCTC RailYatra, my objective was to implement an enterprise-grade, event-driven microservices architecture capable of addressing core distributed systems challenges:

High-concurrency seat contention and race condition mitigation.
Distributed data consistency across boundaries without blocking two-phase commits (2PC).
Fault isolation and recovery using Dead-Letter Queues (DLQ) and circuit breakers.
Sub-50 millisecond inverted-index search across multi-stop schedules.

Here is an analysis of the architectural patterns, trade-offs, and implementation details.

1. System Topology and Domain Boundaries

The platform strictly implements the Database-per-Service pattern. Each microservice encapsulates its domain models, persistence store, and business rules, communicating asynchronously over an event bus or via the edge gateway.

graph TD
    Client[Web and Mobile Clients] -->|HTTPS / REST| APIGW[API Gateway: NGINX / Express]

    subgraph Edge Layer
        APIGW -->|JWT Verification & Rate Limiting| AuthModule[JWT Auth Middleware]
        APIGW -->|Catalog Lookups| SearchService[Search Service]
        APIGW -->|User Domain| UserService[User Service]
        APIGW -->|Reservation Ingestion| BookingService[Booking Service]
        APIGW -->|Payment Processing| PaymentService[Payment Service]
        APIGW -->|Route & Train Master| AdminService[Admin Service]
    end

    subgraph Data Stores
        BookingService -->|Relational State| BookingDB[(PostgreSQL: Booking DB)]
        PaymentService -->|Ledger Records| PaymentDB[(PostgreSQL: Payment DB)]
        InventoryService -->|Berths & Availability| InventoryDB[(PostgreSQL: Inventory DB)]
        AdminService -->|Master Tables| AdminDB[(PostgreSQL: Admin DB)]
        UserService -->|Auth & Profiles| UserDB[(PostgreSQL: User DB)]
        SearchService -->|Denormalized Routes| Elastic[(Elasticsearch)]
        BookingService -->|Atomic Locks & State| RedisCache[(Redis Cluster)]
    end

    subgraph Event Broker: Apache Kafka
        BookingService -->|Event: booking.created| KafkaTopic[Apache Kafka Event Bus]
        PaymentService -->|Event: payment.success / payment.failed| KafkaTopic
        KafkaTopic -->|Consume Events| InventoryService[Inventory Service]
        KafkaTopic -->|Consume Events| NotificationService[Notification Service]
        KafkaTopic -->|Poison Pill Messages| DLQ[Kafka Dead-Letter Queue - DLQ]
    end

Architectural Principles:

API Gateway: Single reverse proxy terminating SSL, executing JWT validation, enforcing sliding-window rate limits, and implementing circuit breakers to prevent cascading failures.
Isolated Relational Stores: Each service maintains its own PostgreSQL instance. Cross-boundary table joins are prohibited at the schema level.
Distributed Message Log (Apache Kafka): Decouples time-sensitive write paths from asynchronous side effects (inventory updates, PDF generation, transactional email dispatch).
In-Memory Locking Layer (Redis): Offloads volatile contention locks from the primary transactional database.
Search Acceleration (Elasticsearch): Houses denormalized route schedules to eliminate multi-table SQL joins during catalog traversal.

2. Concurrency Control: Redis Distributed Locks

Relying on database-level row locking (SELECT ... FOR UPDATE) during high-traffic bursts leads to connection pool saturation, extended lock wait times, and deadlocks.

To resolve this, seat reservation state is temporarily decoupled from the primary database using atomic locks in Redis.

sequenceDiagram
    autonumber
    actor Client as Passenger Client
    participant GW as API Gateway
    participant BS as Booking Service
    participant Redis as Redis Cluster
    participant DB as Booking PostgreSQL
    participant Kafka as Apache Kafka

    Client->>GW: POST /api/bookings/reserve (trainId, seatNo, journeyDate)
    GW->>BS: Validate Token & Forward Request
    BS->>Redis: SET lock:seat:{trainId}:{journeyDate}:{seatNo} {userId} NX EX 600
    alt Lock Contention (Seat Already Reserved)
        Redis-->>BS: nil (Key exists)
        BS-->>Client: 409 Conflict: Seat currently held by another transaction.
    else Lock Acquired (Successful Reservation)
        Redis-->>BS: OK (Exclusive 10-minute hold active)
        BS->>DB: INSERT INTO bookings (status = 'PENDING_PAYMENT')
        BS->>Kafka: Publish `booking.initiated`
        BS-->>Client: 201 Created: Reservation hold active. 10 minutes to complete checkout.
    end

Atomic Lock Implementation with Lua Scripting

To avoid race conditions where a process releases another passenger's newly acquired lock following a timeout, unlock operations must verify ownership atomically:

import Redis from 'ioredis';

const redis = new Redis(process.env.REDIS_URL);

export async function acquireSeatLock(
  trainId: string, 
  seatId: string, 
  journeyDate: string, 
  userId: string,
  holdDurationSeconds = 600 // 10 minutes TTL
): Promise<boolean> {
  const lockKey = `lock:seat:${trainId}:${journeyDate}:${seatId}`;

  // Set if Not eXists (NX) with Expiration Time (EX)
  const status = await redis.set(lockKey, userId, 'NX', 'EX', holdDurationSeconds);
  return status === 'OK';
}

export async function releaseSeatLock(
  trainId: string, 
  seatId: string, 
  journeyDate: string, 
  userId: string
): Promise<boolean> {
  const lockKey = `lock:seat:${trainId}:${journeyDate}:${seatId}`;

  // Lua script ensures atomicity: compare owner before deletion
  const luaScript = `
    if redis.call("get", KEYS[1]) == ARGV[1] then
      return redis.call("del", KEYS[1])
    else
      return 0
    end
  `;

  const result = await redis.eval(luaScript, 1, lockKey, userId);
  return result === 1;
}

3. Distributed Transactions: Choreographed Saga Pattern

Because microservices prohibit distributed ACID transactions across multiple databases, the system applies the Saga Pattern over Apache Kafka to maintain eventual consistency.

sequenceDiagram
    autonumber
    participant Booking as Booking Service
    participant Kafka as Kafka Event Broker
    participant Payment as Payment Service
    participant Inventory as Inventory Service
    participant Notif as Notification Service

    Note over Booking: Phase 1: Reservation Initiated
    Booking->>Kafka: Emit `booking.created`

    Kafka->>Payment: Consume `booking.created`
    Note over Payment: Phase 2: Gateway Execution
    alt Payment Successful
        Payment->>Kafka: Emit `payment.succeeded`
        Kafka->>Inventory: Consume `payment.succeeded`
        Note over Inventory: Phase 3: Final Inventory Decrement
        Inventory->>Kafka: Emit `inventory.confirmed`
        Kafka->>Booking: Transition Status: CONFIRMED
        Kafka->>Notif: Dispatch Confirmation Payload (SendGrid)
    else Payment Declined / Gateway Timeout
        Payment->>Kafka: Emit `payment.failed`
        Note over Booking,Inventory: Compensating Transactions Executed
        Kafka->>Booking: Consume `payment.failed` -> Mark CANCELLED
        Kafka->>Inventory: Consume `payment.failed` -> Release Berth Quota
        Booking->>Booking: Evict Redis Lock Key
    end

Dead-Letter Queues (DLQ) for Poison Pill Handling

When a consumer encounters an unrecoverable deserialization fault or database timeout:

The consumer retries up to three times with exponential backoff.
If failures persist, the message is routed to booking.events.dlq alongside exception headers.
Partition consumption continues without blocking the offset lag of healthy messages.

4. Search Acceleration via Inverted Indexing

Relational tables normalized across trains, intermediate stops, and schedules require expensive joins:
$$\text{Trains} \bowtie \text{Schedules} \bowtie \text{Stations} \bowtie \text{Quotas}$$

During high traffic, read queries against SQL degrade throughput. To optimize this, the Search Service denormalizes train routes into an Elasticsearch index:

{
  "trainNumber": "12002",
  "trainName": "Bhopal Shatabdi Express",
  "sourceStation": "NDLS",
  "destinationStation": "RKMP",
  "stops": [
    { "stationCode": "NDLS", "stationName": "New Delhi", "stopOrder": 1, "departure": "06:00" },
    { "stationCode": "MTJ",  "stationName": "Mathura Jn", "stopOrder": 2, "departure": "07:20" },
    { "stationCode": "AGC",  "stationName": "Agra Cantt",  "stopOrder": 3, "departure": "07:55" },
    { "stationCode": "GWL",  "stationName": "Gwalior Jn",  "stopOrder": 4, "departure": "09:23" }
  ]
}

A nested query checks that both the boarding station and debarkation station exist in stops, verifying that stopOrder(Destination) > stopOrder(Origin). This query completes in under 20 milliseconds, scaling independently of transactional database load.

5. Architectural Trade-Offs & Takeaways

Eventual Consistency vs. Immediate Consistency: Utilizing Saga choreography requires designing consumer logic around idempotency (idempotency_key stored in Redis) to safely handle at-least-once message delivery semantics.
Operational Complexity: Managing separate PostgreSQL instances, Kafka clusters, and Redis instances demands robust container orchestration and centralized structured logging (ELK / Prometheus).
Decoupled Failure Domains: An outage in the Notification Service or Payment Gateway does not compromise catalog availability or schedule lookups.

Author Information

Ramanand Tomar is a Software Engineer specializing in backend distributed architectures, network protocol engineering, and AI systems.

Portfolio: ramanand-tomar.vercel.app
GitHub: github.com/Ramanand-tomar
LinkedIn: linkedin.com/in/ramanand-tomar-478528342