CryptoEx
A crypto-exchange backend project used to study a difficult invariant: one accepted withdrawal request must create at most one external transfer, even when jobs retry or processes fail.
The engineering problem
A withdrawal touches state that cannot be repaired casually. The application needs to validate input, reserve available balance, record the operation, hand work to a retrying worker, communicate with an external provider, and leave enough evidence for an operator to reconstruct what happened.
From order intake to durable settlement
The system separates the fast request path from retryable financial work. Durable identities and database constraints carry correctness across process restarts.
- 01API boundaryValidate identity, amount, market, and idempotency key.
- 02Matching and ledgerApply order rules and commit balance-changing state.
- 03Event and workerPublish durable work that can be retried without repeating value movement.
- 04Provider reconciliationResolve uncertain external responses before another transfer is attempted.
CryptoEx benchmark snapshot
These are project and local benchmark figures, not claims of customer traffic or regulated-exchange scale. Benchmark results only make sense with their implementation and test environment.
- ~150/s
- Orders processedMatching-engine test throughput.
- ~40 ms
- p99 latencyTail latency in the recorded order-path test.
- ~16.9k/s
- Rate-limit checksRedis and Lua limiter benchmark.
- ~11.6k
- Lines of codeApplication and deployment work; not a quality score.
The boundaries documented on this site
- A database transaction owns the withdrawal record and balance reservation.
- A stable idempotency key identifies one logical transfer across retries.
- A durable uniqueness constraint protects the operation after cache keys expire.
- The external provider receives the same idempotency identity when supported.
- Uncertain responses require reconciliation rather than an unsafe blind retry.
Evidence in the guides
- Idempotency in Node.js workers shows the race in a separate check-and-set and the layered Redis, database, and provider protections.
- Node.js backend structure traces a withdrawal from HTTP input through a transaction and asynchronous boundary.
- Scoping a backend portfolio project explains which failure cases make this workflow reviewable.
Honest limits
CryptoEx is presented as an engineering project and portfolio case study, not as a regulated exchange or evidence of real customer volume. Example identifiers and amounts are illustrative. Where a guide discusses production behavior, it describes the failure model being designed for rather than claiming unshown production metrics.
Code and author
See Aarav Chandel's GitHub profile for currently public repositories and project work.