shubham.
Resume ↗
Projects/Systems

TransactX

Payment reliability with retry-safe settlement, health-aware routing and Merkle reconciliation.

2026

297/300 vs 200/300 successful requests in a controlled bank outage.

Payment reliability under partial failure

TransactX connects a Go payment switch, PostgreSQL accounting, independently owned bank services and a React/TypeScript operations console. A transfer must preserve money and keep its identity when a downstream response is lost. Explicit settlement states make successful, failed and unresolved outcomes inspectable throughout the transaction lifecycle.

Customer workflows handle recipients, exact amounts and history. The operations workspace exposes bank health, route decisions, integrity runs and reconciliation differences.

Key mechanisms

  • Customer payments: authenticated accounts and recipients, decimal-to-paise amount handling, stable idempotency attempts, notes, incoming/outgoing history and transaction details.
  • Financial core: integer monetary values, atomic local settlement, balanced debit/credit entries and concurrency protection in PostgreSQL.
  • Distributed settlement: typed bank adapters, durable participant operations, holds, provisional/final credits, compensating actions and persisted saga state.
  • Operations: adaptive routing, circuit breakers, controlled chaos scenarios, Merkle reconciliation, proof verification, integrity runs and a live activity feed.

From request to settlement

  1. Idempotency key
  2. Persisted saga
  3. Bank operation
  4. Ledger state
  5. Reconciliation

The switch and two bank participants own separate records and communicate across HTTP boundaries.

Controlled bank-outage experiment

Adaptive routing297 / 300Successful requests
Static routing200 / 300Successful requests

A 300-request experiment against simulated bank services under controlled outage conditions.

Engineering decisions

Stable participant operation IDs and persisted saga state associate repeated requests with existing work. A retry consults the recorded progress and participant status rather than starting another payment. Each bank owns its balances, holds, operations and ledger; the switch coordinates their HTTP boundaries.

Integer paise avoids floating-point amounts, while double-entry records make the account movement inspectable. Health samples and circuit state guide route selection. Independently maintained Merkle commitments support compact root comparison and targeted inspection of divergent records. Proof verification checks participant, scope, operation and generation context against the trusted root; stale generations are explicit.

SSE updates keep the console connected to changing operation state. Unit, PostgreSQL integration, race-detector and frontend checks exercise payment and integrity paths. The controlled 300-request outage experiment compares adaptive and static routing under the same failure scenario.

↑ ↓ Browse · Enter Open · Esc Close