Reza Heydari
GitHubCV · PDF
← Index / Selected work

Case 02TalaAvan.com / Madar Holding

Gold exchange platform

Back-end for a platform where people trade real, physical gold — built on ElysiaJS and Bun, shipped on Docker.

Role
Senior Back-End Developer (part-time)
Timeline
Mar 2025 – Nov 2025 · 9 mos
Status
Delivered
Stack
TypeScriptElysiaJSBunPrismaMySQLDocker

The problem

TalaAvan lets users buy, hold, and sell gold — not a token that represents gold, the metal itself, held by the business. Every balance in the system is a claim on physical inventory.

That collapses the usual tolerance for eventual consistency: the platform cannot sell gold it doesn't hold, and user balances, order history, and inventory have to agree with each other under a live, moving price.

Constraints

  1. 01

    Part-time engagement — the design had to be right early, because deep rework didn't fit the budget of hours.

  2. 02

    A price that moves constantly: an order is only valid against the quote the user actually accepted, and stale quotes must die, not execute.

  3. 03

    Corporate context (Madar Holding) with an existing operation around the platform — the back-end had to fit their processes, not the other way around.

What I built

The transactional core of the exchange: accounts, orders, balances, and settlement logic, with the database schema designed first and the API shaped around it.

Type-safe HTTP services on ElysiaJS running under Bun — end-to-end TypeScript from route validation to Prisma queries, containerized with Docker for repeatable deploys.

Transaction handling built the way money systems demand: atomic state transitions, no order path that can half-complete, and balances that always reconcile against order history.

Architecture: client orders pass a time-limited quote and a validating API before reaching a transactional core, where database constraints guarantee balances never exceed physical gold inventory.Clientbuy · sellQuotelive gold pricestrict TTL —stale quotes dieElysiaJS · Bunschema-validatedroutes — bad inputunrepresentableTransactional coreaccounts · orders · balances · settlementatomic transitions — no half-completed orderbalances derivable from order historyMySQLconstraintsas lawacceptsvalidated orderevery balance is a claim on physical gold — the system cannot sell what it does not hold
Fig. 02 — system shape, simplified

The hard decision

A young runtime in a money system — deliberately

Choosing Bun and ElysiaJS in 2025 for a commodity exchange raises eyebrows: the boring answer was Node and Express. The developer-experience gains were real — one language and one type system from edge to database, with schema-validated routes that make an entire class of bad input unrepresentable.

The risk was managed, not ignored: the design leans on the database for correctness guarantees (constraints and transactions) rather than on runtime behavior, so the exotic part of the stack was never load-bearing for money safety. If Bun had to be swapped out tomorrow, the correctness story wouldn't move.

Security & reliability

  • Correctness enforced in the schema: database constraints and transactional writes, not application-side hope.

  • Every money movement is an auditable record — balances are derivable from order history at any point in time.

  • Strict input validation at the route layer; nothing reaches business logic unchecked.

  • Docker-based deploys with a known-good rollback image at all times.

Results

months from start to delivered back-end
9
TypeScript, route to database
100%
runtime bet, contained by design
1

What I'd do differently

I'd push for load-testing the quote-acceptance path even earlier. We validated it before launch, but knowing the exact failure profile of the hot path from week one would have let the schema breathe easier.

Building something in this shape?

Email meTelegram — fastest