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.
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.